|
Message-ID: <CACsECNev5Y+XAt_ReizjQRHyY10F2hUb7d8nVJFvzaAW9e8eOg@mail.gmail.com> Date: Wed, 8 Jul 2015 09:13:42 +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 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. Thanks, Alex
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.