[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 Jul 2015 20:27:46 +0200
From: Alex <alexinbeijing@...il.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH v9] Build process uses script to add CFI directives
to x86 asm
On Tue, Jul 7, 2015 at 8:15 PM, Rich Felker <dalias@...c.org> wrote:
> On Tue, Jul 07, 2015 at 06:40:18PM +0200, Alex wrote:
>> On Tue, Jul 7, 2015 at 3:21 PM, Rich Felker <dalias@...c.org> wrote:
>> > On Tue, Jul 07, 2015 at 07:45:34AM +0200, Alex wrote:
>> >> On Tue, Jul 7, 2015 at 5:39 AM, Rich Felker <dalias@...c.org> wrote:
>> >> > On Tue, Jun 23, 2015 at 09:18:08PM +0200, Alex Dowad wrote:
>> >> >> Dear musl devs,
>> >> >>
>> >> >> ../configure now checks CFLAGS as well as CFLAGS_AUTO to see if generation of debug
>> >> >> info was requested.
>> >> >>
>> >> >> The idea of removing duplication from the Makefile using a new AS_CMD variable has
>> >> >> come up several times, but this will not work because the arguments need to be
>> >> >> inserted in different places. I have tried using a Makefile 'define' instead.
>> >> >> Please see whether you like the way this code reads or not.
>> >> >>
>> >> >> Subarch asm files are treated the same as other asm files. Please note that
>> >> >> since I don't own the hardware, I can't test whether these Makefile rules work or not.
>> >> >
>> >> > I'm trying to test this and get it merged, but I'm not having any luck
>> >> > getting gdb to backtrace when I interrupt a syscall with ^C. I've
>> >> > tried pause() and syscall(SYS_pause) (cancellable and non-cancellable)
>> >> > and the patch doesn't seem to help at all for the former, and only
>> >> > helps mildly for the latter. Have you had better results than I did?
>> >>
>> >> I tested a different set of library calls, with my own test programs.
>> >> Can you please send a copy of the test program you are using, and I
>> >> will debug? Thanks, AD
>> >
>> > Here it is. Compile with -g -O0 to make a more interesting backtrace
>> > (if it works).
>>
>> Thanks for the test program. I compiled it with:
>>
>> ../tools/musl-gcc -Xlinker -melf_i386 -m32 -o canbt canbt.c
>>
>> (That -Xlinker junk is because I am compiling to 32-bit code on a
>> 64-bit machine.)
>>
>> And then:
>>
>> gdb ./canbt
>>
>> Set a breakpoint on pause(), single-stepped all the way into the
>> innards of musl, and I was able to get a nice stack trace at each
>> stop. Sample of what it looks like at one randomly chosen point:
>> https://dl.dropboxusercontent.com/u/106217735/musl-debugging-pause.png
>>
>> Could you please 1) tell me the command-line invocation you are using
>> to compile the test program and 2) send me a binary, so I can extract
>> the DWARF data from it and see what it looks like?
>
> 1. Command line is "gcc -g canbt.c". With -static, syscall_cp gets
> optimized out to a normal syscall unless there's a reference to
> pthread_cancel, and the backtrace fully works. It did not work prior
> to your patch. But with dynamic linking, or with pthread_cancel.o
> pulled in when static linking, the backtrace produces (dynamic):
OK, I presume you are testing on a 32-bit OS. Is it Alpine Linux?
> 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.
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.
