Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Jul 2015 09:13:42 +0200
From: Alex <>
To: Rich Felker <>,
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 <> wrote:
> On Tue, Jul 07, 2015 at 08:27:46PM +0200, Alex wrote:
>> > 2. I suspect a dynamic-linked binary without the corresponding
>> > 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
>>, 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 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.


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.