This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: native or target?
- From: Joel Brobecker <brobecker at gnat dot com>
- To: Michael Snyder <msnyder at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 5 Sep 2002 18:02:47 -0700
- Subject: Re: native or target?
- References: <20020905232440.GV1169@gnat.com> <20020905232935.GF1194@gnat.com> <3D77F391.85509705@redhat.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