Re: native or target?

[Kevin Buettner <kevinb@redhat.com>]

[I see Daniel J already answered.  I'll try not to overlap...]

On Sep 5,  4:29pm, Joel Brobecker wrote:

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

No.

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

IMO, [b.] belongs in the tdep module.  However, native ports
frequently make it difficult to do the right thing because the
underlying OS provides ways (via ptrace(), /proc, or other system
dependent methods) to determine certain information which isn't
normally available when using the remote protocol.  It may be the case
that determining sigtramp related addresses can only be done by
examining procfs data structures.  (I don't know anything about
interix and you didn't provide enough code for me to make a
determination.  I'll assume though that since the code in question is
in proc_get_status(), you had a good reason for putting it there.)

Before proceeding, you should study the code in rs6000-tdep.c
which uses rs6000_find_toc_address_hook.  I think this hook is
solving the same kind of problem that you need to solve.  In this
case, there's some code in rs6000-tdep.c which needs to determine the
TOC value for a particular function.  The value in question can't be
determined by examining registers, memory, or information that gdb has
loaded in object files.  The information in question may only be
obtained by making special ptrace() calls.  The mechanism works by
having rs6000-nat.c set the hook to the address of a
(native-dependent) function which'll do the lookup.  The the target
side (i.e.  in the tdep file), you check the hook to see if it's
non-null.  If so, you call the hook to obtain the necessary value.  If
the hook is null, then you fall back as best as possible.

I should note that the gdbarch_data() / set_gdbarch_data() methods
probably ought to be used to manage the hook.  Getting things
initialized correctly can be tricky though so you may want to try it
with a simple global first.  (The global in rs6000-tdep.c ought to be
eliminated at some point.  Note, however, that the mechanism which'll
replace it *won't* be simpler, but it will be able to correctly handle
several different target dependent methods.  It's not clear to me, however,
if this additional complexity will ever actually be useful.)

You may also wish to take a look at native_find_global_pointer in
ia64-tdep.c.  It's solving essentially the same problem, but throws
in another twist.  (See the tdep->find_global_pointer code.)

Kevin