This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: Re: dumper.exe doesn't work
- To: <deo at logos-m dot ru>,<cygwin at sources dot redhat dot com>>
- Subject: Re: Re: dumper.exe doesn't work
- From: "Reinhard JESSICH" <Reinhard dot JESSICH at frequentis dot com>
- Date: Thu, 19 Apr 2001 14:46:53 +0200
- Cc: <reinhard dot jessich at telering dot at>
>>> cgf@redhat.com 04/18/01 10:21pm >>>
> On Wed, Apr 18, 2001 at 11:50:58PM +0400, egor duda wrote:
>Hi!
>
>Wednesday, 18 April, 2001 Christopher Faylor cgf@redhat.com wrote:
>
> >>>i don't think so. maybe gdb snapshots are built without cygwin core
> >>>dumps support? can you build gdb yourself and check? make sure that
> >>>configure finds sys/procfs.h and win32_pstatus_t in it.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ only this, i think.
I have build gdb from source and I saw in the config.h file in the bfd subdirectory, that
HAVE_WIN32_PSTATUS_T is defined. Therefore, I think core dump support is build
in gdb per default. Sorry for making you trouble with this.
Then I have analysed the coredump it was no coredump it was a stack dump from the
cygnus exception handler, I guess.
Here is it:
Exception: STATUS_INTEGER_DIVIDE_BY_ZERO at eip=00401062
eax=00000000 ebx=00000004 ecx=00000000 edx=00000000 esi=6107D0E8 edi=00000002
ebp=0240FBD4 esp=0240FE6C program=C:\cygwin\usr\src\dbz.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
0240FBD4 00401062 (00000000, 00000000, 00000000, 00000000)
.......
0240FFF0 77F1B9EA (00401000, 00000000, 000000B0, 00000100)
End of stack trace
I have found in the list archive, that I have to do the following, to activate dumper.exe.
I have to add "error_start=drive:\\pathtodumper\\dumper.exe" to the CYGWIN
environment variable (I have tried unix path name and this doesn't work).
The problem was, that this never terminated (maybe I have waited to less time,
only 2 Minutes). Then I have used gdb instead of dumper to check if cygnus exception
handler will call any program and this worked.
Please can you tell me what I have done wrong here.
Then I have compiled my test program with the -mno_cygwin switch and installed
dumper instead of DrWatson in the registry as debugger.
This worked now and I got a coredump (.core), but this was not readable by gdb
(gdb --core=.core test.exe says unknown architecture).
Then I have tried objdump --all .core and got:
.core: file format elf32-little
.core
architecture: UNKNOWN!, flags 0x00000000:
^^^^^^^^^^^^^I think this is the problem!!!
start address 0x00000000
Program Header:
LOAD off 0x00000454 vaddr 0x00010000 paddr 0x00000000 align 2**0
filesz 0x00002000 memsz 0x00002000 flags rw-
......
NOTE off 0x00124854 vaddr 0x00000000 paddr 0x00000000 align 2**0
filesz 0x00000112 memsz 0x00000000 flags rw-
......
Sections:
Idx Name Size VMA LMA File off Algn
0 load0 00002000 00010000 00000000 00000454 2**0
CONTENTS, ALLOC, LOAD
......
27 note27 00000112 00000000 00000000 00124854 2**0
CONTENTS
28 .module/00400000 000000f6 00000000 00000000 00124870 2**2
CONTENTS
29 note28 000000f4 00000000 00000000 00124966 2**0
CONTENTS
30 .reg/207 000000cc 00000000 00000000 0012498e 2**2
CONTENTS
31 .reg 000000cc 00000000 00000000 0012498e 2**2
CONTENTS
......
Now I am sure dumper.exe will not produce a valid coredump. Maybe you can tell me
what I have to change in dumper to get a valid one.
Thank you for your help and sorry again to produce work for you with building gdb.
Attached you will find the test program.
Regards,
Reinhard
dbz.c
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple