[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 Jul 2015 14:15:54 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH v9] Build process uses script to add CFI
directives to x86 asm
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):
#0 __cp_end () at src/thread/i386/syscall_cp.s:31
#1 0xb7ffdb70 in builtin_tls () from /lib/ld-musl-i386.so.1
or similar nonsense (static):
#0 __cp_end () at src/thread/i386/syscall_cp.s:31
#1 0x0804a728 in environ ()
My method of testing is running the program under gdb, hitting ^C once
the pause is entered, then attempting bt.
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?
Rich
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.
