This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Post mortem debugging for Windows CE
- From: Danny Backx <danny dot backx at scarlet dot be>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 05 May 2009 15:30:51 +0200
- Subject: Re: Post mortem debugging for Windows CE
- References: <1240929901.29047.110.camel@dannypc> <200904301058.14585.pedro@codesourcery.com> <1241188513.500.41.camel@dannypc> <200905011637.17476.pedro@codesourcery.com>
- Reply-to: danny dot backx at scarlet dot be
It looks like I'm getting close to something that works. Small session
below. Cleanup and more testing are certainly required.
I'm about to look into your suggestion about .module sections.
How can I observe the effect of that ? How can I test ?
Danny
dannypc: {923} gdb/gdb examples/callstack.exe examples/Ce042809-01.kdmp
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=arm-mingw32ce"...
Yow Thread 236B284E Ret Addr 26011178
Yow Register RVA 0x00001760
Yow md 0xa1f58b0 sz 48 nread 48 entries 3
Yow cmp(callstack,callstack)
warning: exec file is newer than core file.
Core was generated by `callstack'.
Yow minidump_core_file_failing_signal -> C0000005
Program terminated with signal 11, Segmentation fault.
[New process 594225230]
Yow arm_minidump_regset_from_core_section
Yow arm_minidump_supply_gregset
#0 0x00011178 in fibo (n=2) at callstack.c:11
11 return *i;
(gdb) bt
#0 0x00011178 in fibo (n=2) at callstack.c:11
#1 0x000111ac in fibo (n=3) at callstack.c:15
#2 0x000111ac in fibo (n=4) at callstack.c:15
#3 0x000111ac in fibo (n=5) at callstack.c:15
#4 0x000111ac in fibo (n=6) at callstack.c:15
#5 0x000111ac in fibo (n=7) at callstack.c:15
#6 0x000111ac in fibo (n=8) at callstack.c:15
#7 0x000111ac in fibo (n=9) at callstack.c:15
#8 0x000111ac in fibo (n=10) at callstack.c:15
#9 0x000111ac in fibo (n=11) at callstack.c:15
#10 0x000111ac in fibo (n=12) at callstack.c:15
#11 0x000111ac in fibo (n=13) at callstack.c:15
#12 0x000111ac in fibo (n=14) at callstack.c:15
#13 0x000111ac in fibo (n=15) at callstack.c:15
#14 0x000111ac in fibo (n=16) at callstack.c:15
#15 0x000111ac in fibo (n=17) at callstack.c:15
#16 0x000111ac in fibo (n=18) at callstack.c:15
#17 0x000111ac in fibo (n=19) at callstack.c:15
#18 0x000111ac in fibo (n=20) at callstack.c:15
#19 0x00011204 in WinMain (a=0x21623686, b=0x0, c=0x2611fed8, d=5) at
callstack.c:22
#20 0x00011134 in WinMainCRTStartup (hInst=0x21623686, hPrevInst=0x0,
lpCmdLine=0x2611fed8,
nCmdShow=5)
at /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/mingw/crt3.c:62
(gdb) up
#1 0x000111ac in fibo (n=3) at callstack.c:15
15 return fibo(n-1) + fibo(n-2);
(gdb)
#2 0x000111ac in fibo (n=4) at callstack.c:15
15 return fibo(n-1) + fibo(n-2);
(gdb) p n
$1 = 4
(gdb) up
#3 0x000111ac in fibo (n=5) at callstack.c:15
15 return fibo(n-1) + fibo(n-2);
(gdb) up
#4 0x000111ac in fibo (n=6) at callstack.c:15
15 return fibo(n-1) + fibo(n-2);
(gdb) p n
$2 = 6
(gdb) info registers
r0 0x2 2
r1 0x0 0
r2 0x2611fed8 638713560
r3 0x0 0
r4 0x21623686 560084614
r5 0x0 0
r6 0x2611fed8 638713560
r7 0x5 5
r8 0x1ffc9e0 33540576
r9 0x2611fed8 638713560
r10 0x21623686 560084614
r11 0x2611fbd0 638712784
r12 0x2611fb34 638712628
sp 0x2611fbac 0x2611fbac
lr 0x111ac 70060
pc 0x111ac 0x111ac <fibo+96>
fps 0x0 0
cpsr 0x0 0
(gdb) q
dannypc: {924}
On Fri, 2009-05-01 at 16:37 +0100, Pedro Alves wrote:
> On Friday 01 May 2009 15:35:13, Danny Backx wrote:
>
> > I've done some of that, but I'm stuck, I have questions.
> >
> > Basically I think I don't find the documentation that says what (from my
> > new minidump-core.c module) is used to implement things like the
> > backtrace command.
>
> GDB needs registers and the thread's stack memory, so it can
> unwind the stack, and needs to be tought about the register layout
> in those ".reg" sections, as that layout differs between machines,
> ABIs, and core file formats.
>
> > warning: "/home/danny/src/gdb/gdb/arm/gdb/examples/Ce042809-01.kdmp": no
> > core file handler recognizes format, using default
>
> You need to fix this. Look at i386-cygwin-tdep.c, and do something
> similar in arm-wince-tdep.c. You'll need to register a new sniffer
> in _initialize_arm_wince_tdep (probably for bfd_target_unknown_flavour
> or for a new minidump flavour you've added?), the sniffer callback can be
> the current `arm_wince_osabi_sniffer' function, but you'll need to
> tweak it to return GDB_OSABI_WINCE for your bfd.
>
> Then, in arm_wince_init_abi, you need to register a
> callback with set_gdbarch_regset_from_core_section that
> extracts the registers from .reg sections.
>
> > I see code that creates ".reg", ".crash", ".data" sections.
>
> > Where can I find documentation for that ?
>
> Docs, who needs stinking docs ?!!!1 :-) I don't know where
> these things are documented, I just look at src/gdb/corelow.c
> to see what GDB expects.
>
> > Are these the things I need to do ?
>
> Yes. In your case, it will be one '.reg/TID' section per thread. The
> thread that was current at the time of the crash gets a literal ".reg"
> section, that lives at the same offset as its corresponding ".reg/TID"
> section. Best look at the sections of a core file on your linux box
> to see what I mean (objdump -h core). You can borrow bits
> from bfd/elf.c:_bfd_elfcore_make_pseudosection for this.
>
> ".crash" isn't used by GDB, it seems specific to cisco cores. It doesn't
> matter the name of the section that contains data (only the
> section flags count), but ".data" is fine.
>
> I (re-)suggest to also add a ".module" section, containing the
> list of loaded dlls, and their load addresses, and then to
> copy the bits from i386-cygwin-tdep.c to arm-wince-tdep.c that
> parse that section --- start with this bit:
>
> set_gdbarch_core_xfer_shared_libraries
> (gdbarch, windows_core_xfer_shared_libraries);
>
> It looks to me that this ends sharing significant chunks of code
> between arm-wince-tdep.c and i386-cygwin-tdep.c, so we
> could move those bits of shared code to windows-tdep.c.
>
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info