native or target?

native or target?

[Joel Brobecker]

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:

  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?

Thanks,
-- 
Joel

Re: native or target?

[Daniel Jacobowitz]

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

Re: native or target?

[Michael Snyder]

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

Re: native or target?

[Kevin Buettner]

[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

Re: native or target?

[Joel Brobecker]

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

Thank you. With your explainations and Daniel's message, I think it's
much clearer in my head now.

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

This is where I am wondering whetherour approach is flawed or not. It
seems very awkward at the very least: procfs is definitely native, but
at the same time the procfinfo data contains these addresses that are
useful for a method which is target dependent...

I need to spend a bit more time understanding why the computation is
done here. I need to do some more research to see if there is no other
way to get these addresses.

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

That's my fault. I confused you with my first example for a question
that was unrelated to the case we are discussing.

I am actually using a native debugger on i386-interix. But I am trying
to fix the few places where we have target-dependent code in native-only
modules. I don't think this is an option to leave these changes there
if I want our interix port to be integrated :-).

BTW: Is it a requirement for a new port to be buildable as a target
only, or can we provide a native-only port as a first step, and then
eventually improve it to support "--host=--target=interix"? This is
out-of-the-box thinking, I don't see how this would help the problem we
have been discussing, but I think this is an interesting piece of
information to know.

> >   What would you do?
> 
> Move them out of procfs, and probably into interix-tdep.

I thought about this. There were several issues that made me
a bit cautious:
  1. interix-tdep can not know about the procinfo structure, since
     this structure is used in native-only debugging. I can still
     get the information because I know the offset of these addresses
     in the procinfo structure. A bit crude, and probably hard to
     maintain as versions of interix evolve, but doable.
  2. I still need somehow to call this function from procfs.c.
     Could it be a new architecture method?

As I said above, I think it is best that I investigate a bit more with
Donn Terry to see if there is no other way to implement PC_IN_SIGTRAMP
in a completely target-oriented way before any of us spends more time on
this.

-- 
Joel

Re: native or target?

[Michael Snyder]

Joel Brobecker wrote:
> 
> > A more accurate definition is that gdb is using the "native"
> > (ie. OS-provided) mechanism for controlling the target
> > program (eg. /proc or ptrace).
> 
> Thank you. With your explainations and Daniel's message, I think it's
> much clearer in my head now.
> 
> > >   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).
> 
> This is where I am wondering whetherour approach is flawed or not. It
> seems very awkward at the very least: procfs is definitely native, but
> at the same time the procfinfo data contains these addresses that are
> useful for a method which is target dependent...
> 
> I need to spend a bit more time understanding why the computation is
> done here. I need to do some more research to see if there is no other
> way to get these addresses.
> 
> > 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?
> 
> That's my fault. I confused you with my first example for a question
> that was unrelated to the case we are discussing.

I see.
 
> I am actually using a native debugger on i386-interix. But I am trying
> to fix the few places where we have target-dependent code in native-only
> modules. I don't think this is an option to leave these changes there
> if I want our interix port to be integrated :-).

It is possible to put something target-specific into procfs, 
but you should isolate it from the rest of the code.  For 
example, see 'procfs_find_LDT_entry'.  That function is only
used by x86-solaris.  But since it is a private access function,
it can't possibly break any other target.

Maybe you could implement your code in a similar way, as a
new function that simply fetches the information that you need.



> BTW: Is it a requirement for a new port to be buildable as a target
> only, or can we provide a native-only port as a first step, and then
> eventually improve it to support "--host=--target=interix"?

Native-only is fine.

> This is
> out-of-the-box thinking, I don't see how this would help the problem we
> have been discussing, but I think this is an interesting piece of
> information to know.
> 
> > >   What would you do?
> >
> > Move them out of procfs, and probably into interix-tdep.
> 
> I thought about this. There were several issues that made me
> a bit cautious:
>   1. interix-tdep can not know about the procinfo structure, since
>      this structure is used in native-only debugging.

Are you saying that interix-tdep may be used for cross-debugging?

If you are cross-debugging (with gdb running on a different host),
how can you do any procfs system calls?  How can you obtain this
address information?

Or, are you simply saying that this code does not fit the 
definition of "target code", because it's more like "native code"?
In that case, you might want to use an "interix-nat.c" module
for it.


>      I can still
>      get the information because I know the offset of these addresses
>      in the procinfo structure. A bit crude, and probably hard to
>      maintain as versions of interix evolve, but doable.
>   2. I still need somehow to call this function from procfs.c.
>      Could it be a new architecture method?

Nah, just an ordinary function call.  Make the function public.


> As I said above, I think it is best that I investigate a bit more with
> Donn Terry to see if there is no other way to implement PC_IN_SIGTRAMP
> in a completely target-oriented way before any of us spends more time on
> this.

OK.

Re: native or target?

[Mark Kettenis]

Joel Brobecker <brobecker@gnat.com> writes:

> > A more accurate definition is that gdb is using the "native"
> > (ie. OS-provided) mechanism for controlling the target 
> > program (eg. /proc or ptrace).
> 
> Thank you. With your explainations and Daniel's message, I think it's
> much clearer in my head now.
> 
> > >   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.

A compile-time test isn't necessarily wrong, although using 

#ifdef SOME_DEFINE_THAT_INDICATES_A_PARTICULAR_OS

is generally frowned upon.  It's better to use a autoconf test for the
feature you're actually using.

> > 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).
> 
> This is where I am wondering whetherour approach is flawed or not. It
> seems very awkward at the very least: procfs is definitely native, but
> at the same time the procfinfo data contains these addresses that are
> useful for a method which is target dependent...

It's not that strange.  The underlying OS has a certain influence on
how a program runs.  In your case it's the location of the signal
trampoline that may vary between OS releases, machines, or the phase
of the moon.  When running natively you can use a system call to
determine where it lives.

> BTW: Is it a requirement for a new port to be buildable as a target
> only, or can we provide a native-only port as a first step, and then
> eventually improve it to support "--host=--target=interix"? This is
> out-of-the-box thinking, I don't see how this would help the problem we
> have been discussing, but I think this is an interesting piece of
> information to know.

I'm inclined to say yes.  If I can configure GDB with
--target=i386-interix on my i386-freebsd system, I can test the
target-dependent code, and you run a smaller risk of me accidentally
breaking your port when making changes to the common i386 code.

> > >   What would you do?
> > 
> > Move them out of procfs, and probably into interix-tdep.
> 
> I thought about this. There were several issues that made me
> a bit cautious:
>   1. interix-tdep can not know about the procinfo structure, since
>      this structure is used in native-only debugging. I can still
>      get the information because I know the offset of these addresses
>      in the procinfo structure. A bit crude, and probably hard to
>      maintain as versions of interix evolve, but doable.
>   2. I still need somehow to call this function from procfs.c.
>      Could it be a new architecture method?
>
> As I said above, I think it is best that I investigate a bit more with
> Donn Terry to see if there is no other way to implement PC_IN_SIGTRAMP
> in a completely target-oriented way before any of us spends more time on
> this.

Well, the current way seems to be a very reliable way to get the
necessary info.  A completely target-oriented way, if it exists, would
probably be less reliable.  It would be great if you could come up
with a solution such thet the info from /proc is used in the native
case.  If you take a look at what I did for FreeBSD/i386 you'll see
that in i386bsd-tdep.c I initialize the variables
i386fbsd_sigtramp_{start|end} to some values that are known to work on
the majority of FreeBSD releases, whereas i386fbsd-nat.c overrides
these values with information from the kernel when running natively.

Perhaps you could do something similar?

Mark

Re: native or target?

[Andrew Cagney]

>
>> BTW: Is it a requirement for a new port to be buildable as a target
>> only, or can we provide a native-only port as a first step, and then
>> eventually improve it to support "--host=--target=interix"? This is
>> out-of-the-box thinking, I don't see how this would help the problem we
>> have been discussing, but I think this is an interesting piece of
>> information to know.
> 
> 
> I'm inclined to say yes.  If I can configure GDB with
> --target=i386-interix on my i386-freebsd system, I can test the
> target-dependent code, and you run a smaller risk of me accidentally
> breaking your port when making changes to the common i386 code.

Two conflicting answers, hmm :-)

It's all smoke and mirrors anyway.  What gets built with the cross 
debugger is determined by what is listed in config/i386/interix.mt.  If 
a file isn't in that list then it won't get built so no one will see the 
problems it contains ;-)  As Mark points out, it is very much to your 
advantage to have all code working as a cross target.

Anyway, I think this thread has identified the need for a 
i386-interix-tdep.c file.  If you haven't already, I think a good easy 
(????) step would be to create an (almost) empty i386-interix-tdep.c 
that just contains the interix ``sniffer''.  Since you'll be needing to 
override architecture methods, you'll definitly need this bit of 
infrastructure working.

Andrew