Re: native or target?

[Mark Kettenis <kettenis at chello dot nl>]

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