Re: native or target?

[Daniel Jacobowitz <drow at mvista dot 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