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

[Daniel Jacobowitz <dmj+@andrew.cmu.edu>]

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