Re: native or target?

[Joel Brobecker <brobecker@gnat.com>]

> 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