Re: native or target?

[Michael Snyder <msnyder at redhat dot com>]

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?

Sure.  Let's take i386-linux for an example.

It can be debugged natively (meaning, the debugger and the program
being debugged are both running on the same machine), or it can
be cross-debugged (the debugger is running on one machine, and the
program being debugged is running on another machine).

If it is cross-debugged, then the debugger might even be 
running on a machine that is not an intel machine, and 
maybe is not even running linux (eg. a sparc solaris machine).

So: if you add code that affects how gdb debugs a 386-linux
program _natively_, then that code goes in i386-linux-nat.c.

If you add code that affects how gdb debugs a 386-linux 
program _no_matter_ where gdb is running, then it goes in
i386-linux-tdep.c.

And of course, if you add code that affects how gdb debugs
_any_ 386 program, then it goes in i386-tdep.c.


> I think part of it is due to the fact that I don't have a clear
> definition of what a native port is. 

A simple but inaccurate definition of "native" is that
gdb is running on the same machine as the target program.

A more accurate definition is that gdb is using the "native"
(ie. OS-provided) mechanism for controlling the target 
program (eg. /proc or ptrace).

An example of "not native" is when gdb uses the remote serial
protocol to debug.  And this illustrates why the first simple
definition of "native" is inaccurate.  It is possible to use
the remote serial protocol to debug a program even if it is
running on the same computer as gdb.  That would not be "native".

> 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?

No.  Look in your build directory -- you should not see i386-nat.o.

> Let's take an example of where I am confused:
> 
>   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 don't understand why you would do this here.
It seems completely unrelated to the function of proc_get_status.

>   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.

I would say this is target code.  Correct me of I am wrong, but
I think you would use the same code regardless of how you were
debugging the target program (procfs or remote).

But I am confused -- you said that GDB is not running on the
target platform, but on a 386-linux machine.  So how can you
use procfs.c?


>   On one hand the procinfo stuff seem to pertain to the native
>   side (hence the -nat module),

procfs.c is DEFINITELY for native debugging ONLY.  It should 
not be used for cross-debugging.


>   but on the other hand, the addresses
>   themselves belong to the interix-tdep module... 

That's correct.

>   What would you do?

Move them out of procfs, and probably into interix-tdep.

>   Or maybe the approach of caching the addresses from the proc
>   information is not viable in the current GDB architecture?

That's what I don't understand.  How can you be using procfs
if your target program is on another machine?  Procfs depends
on making os system calls.

Michael