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

On Thu, 2009-04-30 at 10:58 +0100, Pedro Alves wrote:
> On Thursday 30 April 2009 08:24:41, Danny Backx wrote:
> > On Tue, 2009-04-28 at 17:02 +0100, Pedro Alves wrote:
> > > On Tuesday 28 April 2009 15:45:01, Danny Backx wrote:
> > > > I don't think gdb currently has this capability (to inspect postmortem
> > > > dump files) for debugging CE applications.
> > [..]
> > > If you mean adding gdb support to load minidump files, I can think
> > > of several ways to skin that cat:
> > [..]
> > > 2) teach bfd proper about minidumps, and export the register
> > > set info with fake .reg sections, similarly to how we do for elf
> > > core dumps.  If you export the same set of sections GDB expects from
> > > elf cores (e.g., .reg/XXX sections for thread register sets, .module sections
> > > for loaded dlls.), then the GDB tweaks are the same as
> > > for #1 above.  E.g, teach src/gdb/arm-wince-tdep.c how to extract the loaded
> > > dll list from the core's .module sections.
> > > 
> > > 3) Teach GDB about minidumps, by adding a new minidump target_ops,
> > > similar in vein to src/gdb/corelow.c.  GDB doesn't currenly like
> > > having more than on core file target_ops, though.
> > 
> > I was wondering what is the difference between 2 and 3, and which one is
> > preferred ?
[..]
> I wasn't certain how much of a core dump a minidump is when I
> wrote that; I'm now mostly convinced that 2. is the way
> to go.
> 
> 2. meant putting the minidump file parsing code in bfd.  On
> GDB side, things become mostly transparent.  This is the
> prefered approach.  See all the *-core.c files in bfd for
> starters, e.g. cisco-core.c or ptrace-core.c looks small
> enough to base on.  See also bfd/elf.c, and look for bfd_core,
> and look at all the elfcore_grok_* functions to get a
> feel, specifically, you'll be interested in copying
> elfcore_grok_win32pstatus's NOTE_INFO_MODULE handling.
> I've never done this myself, but it looks to me you'll
> need to follow suit and add a new minidump bfd target, in
> a new bfd/minidump-core.c file.

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.

Here is what it says now :
dannypc: {519} gdb/gdb examples/Ce042809-01.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"...
minidump:Exception Address 0x00011178

warning: "/home/danny/src/gdb/gdb/arm/gdb/examples/Ce042809-01.kdmp": no
core file handler recognizes format, using default

warning: core file may not match specified executable file.
Core was generated by `callstack'.
minidump_core_file_failing_signal -> C0000005
Program terminated with signal 11, Segmentation fault.
Can't fetch registers from this type of core file
Can't fetch registers from this type of core file
#0  0x00000000 in ?? ()
(gdb)  bt
#0  0x00000000 in ?? ()
Can't fetch registers from this type of core file
Can't fetch registers from this type of core file
(gdb) q

(Two of the output lines are debugging code.)

I see code that creates ".reg", ".crash", ".data" sections.
Where can I find documentation for that ? Are these the things I need to
do ?

Thanks,

	Danny

-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info


  reply	other threads:[~2009-05-01 14:35 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 [this message]
2009-05-01 15:37         ` Pedro Alves
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=1241188513.500.41.camel@dannypc \
    --to=danny.backx@scarlet.be \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.com \
    /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