From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: git pull request for tip/tracing/urgent
Date: Wed, 11 Feb 2009 14:40:05 +0100 [thread overview]
Message-ID: <20090211134004.GB5914@nowhere> (raw)
In-Reply-To: <20090211090229.GG21105@elte.hu>
On Wed, Feb 11, 2009 at 10:02:29AM +0100, Ingo Molnar wrote:
>
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
>
> > > >
> > > >
> > > > It thought after the fixup section, the code would continue to rest of the C code.
> > > > Where would it go without the jmp?
> > >
> > > To the next item the linker placed into the .fixup section. And that
> > > would jump back to the location for that fixup. Basically, what you have
> > > is this:
> > >
> > > (just picking random and factitious registers)
> > >
> > > .section .text
> > > [...]
> > > L1: mov %a, %b
> > > L2: cmp %x, $1
> > > <continue code>
> > >
> > >
> > > <Someplace else>
> > >
> > > .section .text
> > > [...]
> > > L3: mov %c, %d
> > > L4: cmp %x, $22
> > > [...]
> > >
> > > .section .fixup
> > > [...]
> > > L5: mov $1, %x
> > > jmp L2
> > > L6: mov $22, %x
> > > jmp L4
> > > [...]
> > >
> > >
> > > .section __ex_table
> > > [...]
> > > .long L1, L5
> > > .long L3, L6
> > > [...]
> > >
> > >
> > > So when we take an exception at label L1, the page fault code will look
> > > to see if it is OK, by doing a binary search of the exception table.
> > > When it finds the L1, L5 pair, it will then set up a return to the L5
> > > label.
> > >
> > > When the fault returns to L5, it loads that reg %x with $1 and jumps back
> > > to L2, where it can see that it took a fault.
> > >
> > > Now lets look at what happens when we do not have that jump back to L2.
> > > Instead of going back to the original code, it will load $22 into %x and
> > > jmp back to the wrong area. God knows what will happen then, since the
> > > stack pointer thinks it is from where the original fault occurred.
> >
> >
> > Heh, that's fairly logic. Don't ask me why, but I did not imagine each
> > part of .fixup unified in a separate contiguous section (but what else can it be?...).
> >
> > Thanks for your explanations :-)
>
> This bit:
>
> ".section .fixup, \"ax\"\n"
> "4: movl $1, %[faulted]\n"
> " jmp 3b\n"
> ".previous\n"
>
> Can be thought of as an 'embedded' or 'nested' section - the '.previous'
> directive jumps back to whatever section we were in before. This can be
> nested multiple times too:
>
> .section A
> [...]
> .section B
> [...]
> .section C
> [...]
> .previous
> [...]
> .previous
> [...]
> .previous
>
> For whatever reason the interaction of the assembler with the linker and
> in particular linker scripts are one of the most undocumented areas of OSS.
> Does anyone know any good reference to start with?
>
> Something that explains the principles, how it all works, what the various
> section flags mean in practice, including details like dwarf2/CFI annotations.
>
> I do not know about any coherent documentation in this area and as a result
> many developers shy away from this area, frequently mess it up if they have to
> touch it and generally treat it as voodoo.
>
> Ingo
When I wrote this part, I used the following documentation:
http://tldp.org/LDP/khg/HyperNews/get/devices/exceptions.html
But yeah, the assembler/linker stuff documentation for gcc are not so much
documented.
There is the raw reference:
http://sourceware.org/binutils/docs/as/index.html
Concerning examples, practical cases, it is exploded on several parts on the web, some good
links can be found on http://asm.sourceforge.net/
Thanks for your explanation.
But I'm confused, if the .previous make a jump to the previous section, then it already
does what jmp 3b does right?
next prev parent reply other threads:[~2009-02-11 13:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-10 18:19 git pull request for tip/tracing/urgent Steven Rostedt
2009-02-10 18:30 ` Frederic Weisbecker
2009-02-10 23:00 ` Steven Rostedt
2009-02-11 1:28 ` Frederic Weisbecker
2009-02-11 9:02 ` Ingo Molnar
2009-02-11 9:16 ` Tejun Heo
2009-02-11 9:53 ` Ingo Molnar
2009-02-12 1:24 ` H. Peter Anvin
2009-02-11 13:40 ` Frederic Weisbecker [this message]
2009-02-11 8:49 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090211134004.GB5914@nowhere \
--to=fweisbec@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.