dumper.exe doesn't work

reinhard.jessich@telering.at reinhard.jessich@telering.at
Sat Apr 21 14:09:00 GMT 2001


On Fri, 20 Apr 2001, egor duda wrote:
RJ> If I call gdb with gdb --core=dbz.exe.core and I do 'info target', 'info threads'
RJ> and 'backtrace' and all worked. But I have not all symbols for the backtrace:
RJ> (gdb) backtrace
RJ> #0  0x77f782db in ?? ()
RJ> #1  0x77f04f37 in ?? ()
RJ> #2  0x6100bd88 in _size_of_stack_reserve__ ()
RJ> #3  0x6100c57c in _size_of_stack_reserve__ ()
RJ> #4  0x77fa7396 in ?? ()
RJ> #5  0x77f9926b in ?? ()
RJ> #6  0x77f86406 in ?? ()
RJ> #7  0x004010ca in main (argc=2, argv=0x1a020ca8) at dbz.c:16
RJ> #8  0x61003859 in _size_of_stack_reserve__ ()
RJ> #9  0x61003a3d in _size_of_stack_reserve__ ()
RJ> #10 0x61003a7c in _size_of_stack_reserve__ ()
RJ> #11 0x0040111f in cygwin_crt0 ()
RJ> I am sure I have compiled it with -g.

ed> you got symbols only for those modules that were compiled so.
ed> you compiled dbz.c w/ debug info, so you see function name and line
ed> number in frame #7. All other frames belong to other modules -- to
ed> cygwin1.dll (addresses 0x610xxxxx) and to windows system dlls
ed> (addresses 0x77fxxxxx). To see symbols there, you should build those
ed> modules w/ debug info too (possible for cygwin1.dll, impossible for
ed> system dlls)
But my test program uses a subroutine and in the subroutine the divide
by zero exception happens. I would expect to see also the subroutine call in
the backtrace.

The test program:

#include <stdio.h>
void smokeoff( void )
{
   int i,j;
   for( i = 1; i < 100; i = ( i + 1 ) % 99 )
   {
      j /= i;
   }
}

int main( int argc,char *argv[] )
{
   if( argc > 1 )
   {
      smokeoff();
   }
   return 0;
}

As you can see the exception sould be in the line "j /= i;". I don't know if
this division is done by a system dll or by code generated by the compiler.
I guess it is the latter one, because it is an integer division.

I would also expect to see the locals for example the i or j. But gdb says that
this symbols are unknown. Mabe this is because of the message if I start
gdb "core file may not match specified exec-file".

> RJ> Is there something missing in the dumper or gdb implementation?
> RJ> Is symbol writing not implemented in dumper?
 
ed> symbols are not written to core dump to save space. they're taken from
ed> program and dlls when gdb loads dump.
But this seems to be the problem (gdb starting message above). The core dump
size is still 1,2 Mb. I don't know if it is possible to write symbols to the
core dump. Are they available from dumper if it attaches to a process?

If I start gdb with the core and the executable, I would expect, that gdb
jumps to the exception position and I can step back to the call stack
and see all local variables to find the error in my program.
Is this also what you have implemented?
  If the answer is yes, then this will not work in my environment. Maybe
you can point me in the right direction to find the error.
  If the answer is no, what needs to be done to get this working? I can
help you to implement this if it is not to much work. I am familar with
C/C++ programming. I have experience in embedded programming for
telecomunication. I have no experience in making a compiler or debugger,
but if you tell me what to do I will help you.

My problem is that with MS Tools we can produce a core dump and windbg
can read this. The functionality is approximatly the same as at Linux with
gdb. I would like to use the GNU tools chain, but my boss tells me that we
need this coredump feature. So if this will not work, I have to work with
Visual C++ and I hate it.
So, please help me to avoid this MS Tools
     Reinhard

-- 
 Ing. Reinhard Jessich              mailto: reinhard.jessich@telering.at
 A-1190 Vienna, Goergengasse 2/2/1  phone: +43/1/3692600
 http://members.telering.at/jessich mobile: +43/664/1735439

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple



More information about the Cygwin mailing list