nm.h, *-nat.c and multi-arch?

nm.h, *-nat.c and multi-arch?

[Andrew Cagney]

Hello,

I'm trying to eliminate xm.h, tm.h and possibly nm.h.  Part of that is 
actually understanding what should and what should not be in a nm.h and 
*-nat.c.

xm.h is pretty easy, it can be replaced by autoconf magic.  As they say, 
It is now ``done stage 7 - it was seen to work once'' (cf NetBSD/PPC).

tm.h is also straight forward.  It has been replaced by the gdbarch 
vector (gdbarch.h/c) and extra *-tdep.c code.

nm.h and *-nat.c, however are more interesting.  Studying the code I 
think it has been used for:

	o	interface code to make
		procfs, ptrace, ... work

		See below.

	o	Stuff that should have
		been put in the xm file.

		I'll pretend this didn't
		happen :-)

	o	Stuff that should have been
		put in a tm file.

		Ditto :-)

	o	OS specific info for
		standard features (core file,
		shared libraries, ...).

		This is now also being moved to gdbarch
		and being made host independant.  It
		is definitly a WIP though.

		See wart below.

	o	customize to enable
		extra (OS/arch specific?) features.
		(The i386 hw breakpoint code
		comes to mind.)

		Here again, I think this should really
		be host independant.

		See wart below.

Ignoring the warts, this just leaves the the first case.  As best as I 
can tell, the only things that, strictly speaking, should be in nm.h and 
*-nat.c are macros/functions that enable the native interface code 
(procfs, ptrace, ...).  Having an nm.h for those files is probably ok 
since procfs.[hc] is HOST=TARGET specific.

Anyway, this in turn begs the (for the moment largely accademic) 
question should procfs.c et.al. include nm.h directly instead of having 
defs.h include it.

--

The wart?  So far multi-arch has concentrated on problems like:

	MIPS2 embedded
	MIPS3 embedded

but has avoided cases such as:

	Linux/MIPS native and remote
	MIPS embedded
	*BSD/MIPS remote

i.e. OS as well as ISA/ABI as a variant.  For nm.h to be reduced to just 
_native_ interface support, multi-arch will need to be extended to 
include this.

	Andrew

Re: nm.h, *-nat.c and multi-arch?

[Eli Zaretskii]

> Date: Wed, 04 Jul 2001 12:11:58 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> 	o	customize to enable
> 		extra (OS/arch specific?) features.
> 		(The i386 hw breakpoint code
> 		comes to mind.)
> 
> 		Here again, I think this should really
> 		be host independant.

I don't think it's possible, based on many hours of staring at the
various implementations of hw breakpoints.  The differences are not
always major, but IMHO significant enough to render any attempt to
unify them be a huge effort with a very small benefit.

Even IA64 is sufficiently different from IA32 so as to prevent any
reasonable attempt to unify the code which handles watchpoints.

Re: nm.h, *-nat.c and multi-arch?

[Andrew Cagney]

> Date: Wed, 04 Jul 2001 12:11:58 -0400
>> From: Andrew Cagney <ac131313@cygnus.com>
>> 
>> o	customize to enable
>> extra (OS/arch specific?) features.
>> (The i386 hw breakpoint code
>> comes to mind.)
>> 
>> Here again, I think this should really
>> be host independant.
> 
> 
> I don't think it's possible, based on many hours of staring at the
> various implementations of hw breakpoints.  The differences are not
> always major, but IMHO significant enough to render any attempt to
> unify them be a huge effort with a very small benefit.
> 
> Even IA64 is sufficiently different from IA32 so as to prevent any
> reasonable attempt to unify the code which handles watchpoints.


I suspect I misspook.  I wouldn't expect some sort of unification of 
hardware breakpoints between different architectures (ia 32 vs ia 64). 
I was thinking more of better unification within an architecture.

For instance, a hardware breakpoint mechanism implemented purely as 
register reads/writes shouldn't need to do anything like access ptrace() 
directly.  Instead it should just access the target layer below it which 
(hopefully) is making available all the registers it needs.

A hardware breakpoint mechanism that required magic system calls, on the 
other hand, should be part of NAT.

	Andrew

Re: nm.h, *-nat.c and multi-arch?

[Eli Zaretskii]

> Date: Wed, 04 Jul 2001 14:35:35 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> For instance, a hardware breakpoint mechanism implemented purely as 
> register reads/writes shouldn't need to do anything like access ptrace() 
> directly.  Instead it should just access the target layer below it which 
> (hopefully) is making available all the registers it needs.

Now I'm confused ;-) How can you access the debug registers except via
ptrace, procfs, etc.?  Even DJGPP needs a bunch of system calls to do
that, since the debug registers are not directly accessible to DPMI
applications.

The last episode of the x86 watchpoint support was an attempt to
generalize the magic system calls used on various platforms to access
debug registers.  But direct access to these registers is probably
possible only on embedded targets, where there's no OS to get in the
way.

Re: nm.h, *-nat.c and multi-arch?

[Daniel Jacobowitz]

Speak of the devil...

On Wed, Jul 04, 2001 at 12:11:58PM -0400, Andrew Cagney wrote:
> 	o	interface code to make
> 		procfs, ptrace, ... work
> 
> 		See below.

What I would actually like to see, as I've mentioned before, would be
the -nat.c and nm.h files shrink but probably not vanish.  This would
let us reuse them in gdbserver.  I'm still not clear on how practical
that is, though.

> 	o	Stuff that should have
> 		been put in the xm file.
> 
> 		I'll pretend this didn't
> 		happen :-)
> 
> 	o	Stuff that should have been
> 		put in a tm file.
> 
> 		Ditto :-)

La de da di da..... nothing to see here, move along.

> The wart?  So far multi-arch has concentrated on problems like:
> 
> 	MIPS2 embedded
> 	MIPS3 embedded
> 
> but has avoided cases such as:
> 
> 	Linux/MIPS native and remote
> 	MIPS embedded
> 	*BSD/MIPS remote
> 
> i.e. OS as well as ISA/ABI as a variant.  For nm.h to be reduced to just 
> _native_ interface support, multi-arch will need to be extended to 
> include this.

Here we are.  As I get further through this port, which I'm actually
probably going to post today, hacks and all, I have been wondering what
it will do to multi-arch.  I don't see how to specify what the default
OS is properly; and worse yet are things like:the ELF header flag
indicating O32 ABI is actually far more recent than the O32 spec, and
may even violate it, so Linux has to assume that unmarked binaries are
O32.  So something like MIPS_DEFAULT_ABI may need to become
multi-arched too.  Etc.

The other thing I have on my plate is cross-platform corefile support. 
I have the BFD side of this approved and mostly committed now.  Which
brings me to core-regset.c.  Is it worth trying to convert all targets
at once, if that's even possible, or should I introduce a parallel file
to replace it?  My general plan is to add a table of (note type, size,
supply function) tuples to the multiarch vector, so that core-regset.c
does not need to use the gdb_gregset_t type.  Attempting to do that
cross is more pain than it's worth, IMO.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer