This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Post mortem debugging for Windows CE


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]