This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: native or target?
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Joel Brobecker <brobecker at gnat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 5 Sep 2002 19:35:48 -0400
- Subject: Re: native or target?
- References: <20020905232440.GV1169@gnat.com> <20020905232935.GF1194@gnat.com>
On Thu, Sep 05, 2002 at 04:29:35PM -0700, Joel Brobecker wrote:
> Hello,
>
> I have read the gdbint documentation, but still sometimes have some
> difficulties deciding where some of the pieces of code should be going.
> Should be -nat, or -tdep? Difficult to say sometimes. Can anyone help
> me?
>
> I think part of it is due to the fact that I don't have a clear
> definition of what a native port is. I suppose native is when host and
> target are the same? I don't have a recent cross-debugger handy to check
> that: if I am running on a x86-linux machine cross ppc, is the code in
> i386-nat.c used?
>
> Let's take an example of where I am confused:
A native port is something which runs natively, and speaks to some
native debug interface. A cross debugger uses some sort of remote
target. But it still needs to understand the target.
> On interix, the PC_IN_SIGTRAMP method works by comparing the
> PC address against a set of addresses. These addresses are actually
> to computed at the time when the comparison is made, but were
> cached earlier.
>
> One of the places where these addresses are computed is in the
> procfs module (ie we deduct these addresses from the proc info).
> Right now, our code looks like this:
>
> proc_get_status (procinfo *pi)
> {
> [a. normal processing]
> #ifdef __INTERIX
> [b. compute sigtramp-related addresses from proc info]
> #endif
> [c. rest of normal processing]
> }
>
> I would like to move the code in [b.] to the right place, and then
> remplace the #ifdef __INTERIX section by the proper runtime test.
> But I am confused as to where the right place for this code would
> be. On one hand the procinfo stuff seem to pertain to the native
> side (hence the -nat module), but on the other hand, the addresses
> themselves belong to the interix-tdep module... What would you do?
>
> Or maybe the approach of caching the addresses from the proc
> information is not viable in the current GDB architecture?
It's as viable as it ever was - and as incorrect as it ever was! The
right place to calculate this information is in a function in your tdep
file, if you can. It is often easier to do this sort of thing
natively, so people take shortcuts. Basically, if it pertains to a
computation that an interix-targeted debugger needs, then it should not
be in a native-dependant file. procfs code is native-dependent.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer