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.