Brian Dessent wrote:
> Yes, it means there is one frame that says "sigbe" instead of the actual
> return location somewhere else. I don't think that's impossible to fix
> either: the fault handler gets the context of the faulting thread so it
> can look up its tls area through %fs:4 and peek at t
Brian Dessent wrote:
> I think I see what's going on here though, the Cygwin fault handler took
> the first chance exception and wrote the stackdump file, and only then
> passed it on to the debugger, so that by the time gdb got notice of the
> fault the stack was all fubar. This could be the rea
On Thu, Mar 20, 2008 at 11:23:05AM -0700, Brian Dessent wrote:
>Corinna Vinschen wrote:
>
>> 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 w
Corinna Vinschen wrote:
> 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 stackdu
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
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 t
