This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: native or target?


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]