A Wednesday 19 March 2008 15:56:55, 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: > > $ gdb > (gdb) core a.exe.core > [New process 1] > [New process 0] > [New process 0] > #0 0x7c90eb94 in ?? () > (gdb) thr apply all bt > > Thread 3 (process 0): > #0 0x7c90eb94 in ?? () > > Thread 2 (process 0): > #0 0x7c90eb94 in ?? () > > Thread 1 (process 1): > #0 0x7c90eb94 in ?? () > > You can't even make out the names of any of the loaded modules from the > core: >
Sorry I missed the discussion at [EMAIL PROTECTED] 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? > that this patch introduces. Plus without being able to recognise that > signal wrappers obscure the location of the real entrypoints to > many/most Cygwin functions, the backtrace used by this method looks very > bad and doesn't give useful information for routines in Cygwin -- and > being able to do that processing is much easier when you're in the > actual module that has the wrappers as you can simply test against > &_sigfe. Is this something that would be nice to have in gdb then? -- Pedro Alves
