[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150708141112.GM1173@brightrain.aerifal.cx>
Date: Wed, 8 Jul 2015 10:11:12 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH v9] Build process uses script to add CFI
directives to x86 asm
On Wed, Jul 08, 2015 at 09:54:55AM +0200, Alex wrote:
> On Wed, Jul 8, 2015 at 9:13 AM, Alex <alexinbeijing@...il.com> wrote:
> > On Wed, Jul 8, 2015 at 4:36 AM, Rich Felker <dalias@...c.org> wrote:
> >> On Tue, Jul 07, 2015 at 08:27:46PM +0200, Alex wrote:
> >>> > 2. I suspect a dynamic-linked binary without the corresponding libc.so
> >>> > is not useful. Do you want the static-linked binary with a reference
> >>> > to pthread_cancel added?
> >>>
> >>> I want to see the DWARF data, and in this case it should be in
> >>> libc.so, not in canbt. But let me test under conditions more similar
> >>> to yours first.
> >>
> >> I'm attaching the static a.out which exhibits the problem, and sending
> >> this off-list since it's (mildly) big. I can send libc.so if you
> >> prefer but I think the static version is sufficient to see the
> >> problem.
> >
> > Thanks. The problem was nothing to do with differences in our build
> > environments. The problem was that in src/thread/i386/syscall_cp.s,
> > _syscall_cp_asm "falls through" into __cp_begin.
> >
> > The CFI generation process assumes that each "global" label is a call
> > target, and hence when a global label is reached, the stack frame
> > offset should be 4. It assumes that we must have reached the current
> > point from a CALL, and that the return address should be on the top of
> > the stack.
> >
> > In this case, __cp_begin is NOT a call target. (It is used in
> > pthread_cancel.c:cancel_handler, which checks whether a saved
> > instruction pointer value is between __cp_begin and __cp_end.)
> >
> > I will amend the script so that it must see a ".global" directive
> > *and* a ".type @function" directive before it assumes that a label is
> > an entry point for C function calls.
I'm a little bit skeptical of this approach, but it probably does work
in practice. Stack pointer should be non-adjusted at any callable
external symbol. The exceptions are the __cp_* labels and they (at
present) are not function-type, but may need to be function-type on
arm once we support thumb2 asm because I think the thumb bit gets lost
without function-type (but maybe it doesn't matter). In any case that
doesn't affect x86.
> A couple questions:
>
> drem(), dremf(), and vfork() are declared as ".type @function", but
> not ".global". Rather, they use ".weak" directives. Are such labels to
> be considered entry points?
Yes, they are entry points, and I think having vfork be weak is wrong
anyway (it was from back when we had other code in musl calling
__vfork, which was a bad idea).
> Then there are some labels which are declared as ".global" and
> ".hidden", like __memcpy_fwd, __exp2l, and ___setjmp. It looks like
> when any of those 3 are reached, there should be a return address on
> top of the stack. What would you think of adding a ".type @function"
> declaration for those 3, so that the CFI generation script will treat
> them as "functions"?
Do these matter? The exact same address is already an entry point
via the other public name(s) you're supposed to use for it.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
