This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: [PATCH] better stackdumps
Pedro Alves wrote:
> Sorry I missed the discussion at gdb@. What does info sharelibrary say?
> The last I looked at this, it worked. Is this broken in gdb head
> and on the cygwin distributed gdb?
With gdb CVS HEAD, it gives:
(gdb) i sh
>From To Syms Read Shared Object Library
0x7c901000 0x7c9afe88 No C:\WINXP\system32\ntdll.dll
0x7c801000 0x7c8f4bec No C:\WINXP\system32\kernel32.dll
0x61001000 0x61280000 No C:\cygwin\bin\cygwin1.dll
0x77dd1000 0x77e6ab38 No C:\WINXP\system32\ADVAPI32.DLL
0x77e71000 0x77f01464 No C:\WINXP\system32\RPCRT4.dll
0x77fe1000 0x77ff0884 No C:\WINXP\system32\Secur32.dll
0x77b41000 0x77b61360 No C:\WINXP\system32\Apphelp.dll
And after that, the backtrace can at least name the DLL, but is still
otherwise useless:
(gdb) thr apply all bt
Thread 3 (process 0):
#0 0x7c90eb94 in ?? () from C:\WINXP\system32\ntdll.dll
Thread 2 (process 0):
#0 0x7c90eb94 in ?? () from C:\WINXP\system32\ntdll.dll
Thread 1 (process 1):
#0 0x7c90eb94 in ?? () from C:\WINXP\system32\ntdll.dll
"info target" still lists every section as just "loadnn".
With gdb 6.5.50.20060706 as packaged by Cygwin, the result is
approximately the same except with posix paths (and the main .exe module
is present too):
(gdb) i sh
>From To Syms Read Shared Object Library
0x00401000 0x004013d0 No
/home/brian/testcases/backtrace/a.exe
0x7c901000 0x7c97b6fe No /winxp/system32/ntdll.dll
0x7c801000 0x7c883111 No /winxp/system32/kernel32.dll
0x61001000 0x61118994 No /usr/bin/cygwin1.dll
0x77dd1000 0x77e452d9 No /winxp/system32/advapi32.dll
0x77e71000 0x77ef3353 No /winxp/system32/rpcrt4.dll
0x77fe1000 0x77fed1dc No /winxp/system32/secur32.dll
0x77b41000 0x77b5d60c No /winxp/system32/apphelp.dll
(gdb) thr apply all bt
Thread 3 (process 4992):
#0 0x7c95077b in ntdll!KiIntSystemCall () from
/winxp/system32/ntdll.dll
Thread 2 (process 6304):
#0 0x7c90eb94 in ntdll!LdrAccessResource () from
/winxp/system32/ntdll.dll
Cannot access memory at address 0x7c90eb94
Thread 1 (process 8100):
#0 0x7c90eb94 in ntdll!LdrAccessResource () from
/winxp/system32/ntdll.dll
Cannot access memory at address 0x7c90eb94
In both cases the core was produced by current Cygwin CVS dumper.exe.
> Is this something that would be nice to have in gdb then?
If gdb has debug symbols available then it's irrelevent because the info
there is correct: the address for printf in the symbols is the real
function. It's just that the thing exported as "printf" by the DLL
actually points to _sigfe_printf, which is of course the whole point of
the wrappers. So this matters only to code that's not using debug
symbols but just looking at export tables. Now certainly gdb does that
a lot too so I suppose it would be nice to have there, but the main case
where cygwin1.dbg is present is unaffected.
The problem with adapting it for gdb is that _sigfe is not a public
symbol and so the heuristic for detecting a signal wrapper would have to
either loosely trigger on any entry that starts with the "push/jmp"
sequence, or it would have to somehow otherwise figure out the location
of _sigfe so that it can verify the location of the jmp before calling
it a wrapper. Realistically if the heuristic is going to be limited to
cygwin1.dll then I suppose it's not such a risk to assume any entrypoint
that starts out that way is in fact a signal wrapper: by my count 1036
of the current 1749 exports of the DLL are wrapped this way.
Brian