Re: Better debugging support in Mach

[Thomas Schwinge]

Hi!

On Mon, 26 Mar 2012 21:51:18 +0200, ludo@gnu.org (Ludovic 
=?iso-8859-1?Q?Court=E8s?=) wrote:
> Samuel Thibault <samuel.thibault@gnu.org> skribis:
> 
> > Ludovic Courtès, le Sat 24 Mar 2012 22:24:38 +0100, a écrit :
> >> There might still be something wrong with the user-space stack trace
> >> though, but it could be due to something else:
> >> 
> >>   $ addr2line -pfa -e 
> >> /nix/store/dsw2yh0sxidmijg2y3vjps1mqjvx6q5w-hurd-0-i586-pc-gnu/hurd/auth 
> >> 0x103ac23
> >>   0x0103ac23: ??
> >>   ??:0
> >> 
> >> (The Hurd above is compiled with -O1.)
> >
> > Is it compiled with -fno-omit-frame-pointer too?  -O enables omitting
> > frame pointers "where doing so does not interfere with debugging.", but
> > the mach debugger is probably very poor in that regard.

s%probably%%

> Yes, but ‘-fomit-frame-pointer’ is enabled “at levels `-O', `-O2',
> `-O3', `-Os'” (info "(gcc) Optimize Options").
> 
> Anyway, building with “-O1 -fno-omit-frame-pointer” yields slightly
> better, yet imperfect traces:
> 
>   db> show task
>       TASK        THREADS
>     5 (e0823c60): 4 threads:
>                 0 (e083e548) R   F
>                 1 (e083e2a8)  W   (0xc014c4b0) 0
>                 2 (e084ce80) R    (0xc014c4b0)
>                 3 (e084cbe0)  W   (0xc014c620) 0
>   db> trace/tu
>   0xc011eae9(c027c819,e0823c60,17,e083e548,e0847ef8)
>   0xc014ee59(e0820dc0,17,e0847ef8,128bc70,a)
>   0xc01529dc(1,17,e0847ef8,e0824d20,ea0359c8)
>   0xc0106d40(128fdbc,2000,a,800,0)
>   >>>>> user space <<<<<
>   0x103ac3d(1,0,0,0,3a)
>   0x103af69(804ccf8,80494ec,7530,0,0)
>   0x804a2a3(1,128fed4,128fedc,f3d4,128fed4)
>   Bad frame pointer: 0x1
> 
> and:
> 
>   $ addr2line -pfa -e result/hurd/auth 0x103ac3d 0x103af69 0x804a2a3
>   0x0103ac3d: ??
>   ??:0
>   0x0103af69: ??
>   ??:0
>   0x0804a2a3: main at 
> /tmp/nix-build-3bm2lp9lkj6bczd61p9qj1ramlpxy7wh-hurd-0-i586-pc-gnu.drv-0/hurd-20120326/auth/auth.c:523
> 
> The strange thing is that the top-most part is correct.

I would bet this is ld.so/libc.so/etc.  Not matching your /hurd/auth
binary, but compare:

    $ ldd /hurd/auth 
            libhurdbugaddr.so.0.3 => /lib/libhurdbugaddr.so.0.3 (0x01040000)
            libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x01042000)
            libports.so.0.3 => /lib/libports.so.0.3 (0x01049000)
            libihash.so.0.3 => /lib/libihash.so.0.3 (0x01053000)
            libshouldbeinlibc.so.0.3 => /lib/libshouldbeinlibc.so.0.3 
(0x01056000)
            libc.so.0.3 => /lib/i386-gnu/libc.so.0.3 (0x01062000)
            /lib/ld.so => /lib/ld.so.1 (0x00001000)
            libmachuser.so.1 => /lib/i386-gnu/libmachuser.so.1 (0x011f7000)
            libhurduser.so.0.3 => /lib/i386-gnu/libhurduser.so.0.3 (0x0120b000)

Might this work (hooray for no address space randomization); on the
GNU/Hurd system:

    $ gdb -q /hurd/auth
    (gdb) start
    (gdb) info symbol *0x0103ac3d


Grüße,
 Thomas

pgpkhGw401YHQ.pgp
Description: PGP signature