This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: cross-debugging of userland core files, nat -> tdep
- From: Michael Snyder <msnyder at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Jason R Thorpe <thorpej at wasabisystems dot com>, gdb at sources dot redhat dot com
- Date: Thu, 11 Apr 2002 14:27:06 -0700
- Subject: Re: cross-debugging of userland core files, nat -> tdep
- Organization: Red Hat, Inc.
- References: <20020410183918.C22095@dr-evil.shagadelic.org> <20020410215824.A6539@nevyn.them.org>
Daniel Jacobowitz wrote:
>
> On Wed, Apr 10, 2002 at 06:39:18PM -0700, Jason R Thorpe wrote:
> > Hi folks...
> >
> > I've been thinking of what needs to happen in order to support
> > cross-debugging of userland core files in NetBSD.
> >
> > BFD can already handle NetBSD ELF core files in the appropriate way. As
> > far as I can tell, the only stumbling block is getting GDB to play nicely
> > with them.
> >
> > The problem is that the functions that supply registers, etc. from the core
> > file are all in "nat" modules. This is probably mostly an artifact of the
> > data being in the same format as the reg structure returned by ptrace(2).
> >
> > What I'd like to do is move those supply-registers routines into an
> > appropriate "tdep" file. They can still be used by the "nat" routines
> > which use ptrace(2), and all the core file handling goo can then go into
> > the "tdep" module, as well.
> >
> > If this sounds reasonable, then I'll start my little project. Otherwise,
> > I'd love to hear suggestions :-)
>
> Hit the nail on the head. I believe I've gotten BFD to understand ELF
> core files appropriately for a fair number of targets; you may need to
> add a platform-specific chunk to all the ones I didn't get to. Then
> move supply_* out of the nat files, and link in the core code.
>
> Now, if you've got time, there's a much better way to do this. The
> "magic" supply_* and fetch_* names need to go; we should instead have a
> table of regset types, sizes, and fetch/supply functions. I just
> haven't gotten around to actually doing that.
Nathaniel, I will kiss your feet if you will do that. ;-)
That would mean I could pretty easily implement the gcore command
for embedded gdb.