[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACsECNedQxgEGcpiPwZxyhoP6G2JPXKE12GrC_C4ux6qikjDfA@mail.gmail.com>
Date: Wed, 8 Jul 2015 09:54:55 +0200
From: Alex <alexinbeijing@...il.com>
To: Rich Felker <dalias@...c.org>, musl@...ts.openwall.com
Subject: Re: [PATCH v9] Build process uses script to add CFI directives
to x86 asm
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.
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?
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"?
Thanks, AD
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.
