Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: danny.backx@scarlet.be
Cc: gdb-patches@sourceware.org
Subject: Re: Post mortem debugging for Windows CE
Date: Fri, 01 May 2009 15:37:00 -0000	[thread overview]
Message-ID: <200905011637.17476.pedro@codesourcery.com> (raw)
In-Reply-To: <1241188513.500.41.camel@dannypc>

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.

-- 
Pedro Alves


  reply	other threads:[~2009-05-01 15:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-28 14:45 Danny Backx
2009-04-28 16:02 ` Pedro Alves
2009-04-28 17:48   ` Danny Backx
2009-04-28 19:18     ` Danny Backx
2009-04-29  7:10       ` Eli Zaretskii
2009-04-29  7:19         ` Danny Backx
2009-04-29  7:44           ` Eli Zaretskii
2009-04-30  7:25   ` Danny Backx
2009-04-30  9:58     ` Pedro Alves
2009-05-01 14:35       ` Danny Backx
2009-05-01 15:37         ` Pedro Alves [this message]
2009-05-05 13:31           ` Danny Backx
2009-05-05 16:53             ` Pedro Alves
2009-05-06 14:13               ` Danny Backx
2009-05-06 14:34                 ` Pedro Alves
2009-05-06 20:05                   ` Danny Backx
2009-05-06 20:47                     ` Pedro Alves
2009-05-07  1:21                       ` Danny Backx
2009-05-10 19:21                         ` Pedro Alves
2009-05-11 14:03                           ` Danny Backx
2009-05-11 15:00                             ` Danny Backx

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200905011637.17476.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=danny.backx@scarlet.be \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox