[PATCH] better stackdumps

[Christopher Faylor]

On Thu, Mar 20, 2008 at 11:35:32AM +0100, Corinna Vinschen wrote:
>On Mar 19 08:56, Brian Dessent wrote:
>> Christopher Faylor wrote:
>> 
>> > Sorry, but I don't like this concept.  This bloats the cygwin DLL for a
>> > condition that would be better served by either using gdb or generating
>> > a real coredump.
>> 
>> I hear you, but part of the motivation for writing this was a recent
>> thread the other week on the gdb list where the poster asked how to get
>> symbols in a Cygwin stackdump file.  I suggested the same thing, setting
>> error_start=dumper to get a real core dump.  They did, and the result
>> was completely useless.  Here is what dumper gives you for the same
>> simple testcase:
>> [...]
>> addr2line also seems to be totally unequipped to deal with separate .dbg
>> information, as I can't get it to output a thing even though both a.exe
>> and cygwin1.dll have full debug symbols:
>> 
>> $ addr2line -e a.exe 0x610F74B1
>> ??:0
>
>Is it a big problem to fix addr2line to deal with .dbg files?
>
>I like your idea to add names to the stackdump especially because of
>addr2line's brokenness.  But, actually, if addr2line would work with
>.dbg files, there would be no reason to add this to the stackdump file.

There's still the issue of dealing with the separate signal stack.  That
makes stack dumps less than useful.

However, I would really love it if gdb was able to decode this information
automatically.

The bottom line is that I think that rather than modifying cygwin to
work around the limitations of the tools we should be fixing the tools.

But, then, that puts the problem back on my shoulders as the gdb and
binutils maintainer.

PTC.

cgf