Re: Pass gdbarch, not regset, to supply regset et.al.?

[Andrew Cagney <ac131313@redhat.com>]

> * It's a bit of a hassle to get at the right architecture from within
>   a *-nat.c module.

(it's a bit of a hassle more generally too :-) target->lwp->architecture?

> * There are cases where there are several implied architectures to
>   choose from.
> * What's the implied architecture of an architecture-independent
>   remote protocol?  I'd like to make these register sets work for
>   remote protocols too, without havong to associate some sort og
>   "generic" gdbarch with it.

>    > Well, you can always pass gdbarch as the description.  The point is
>    > that the current implementation makes it possible to pass in something
>    > that isn't related to a gdbarch at all.  I also think it doesn't
>    > necessarily make sense to copy the i386 implementation.  For SPARC I'm
>    > already thinking about a somewhat different implementation.
> 
>    Will anyone every actually do this, or have we ended up with too much 
>    generality?
> 
> There might be too much generality, but that's certainly better than
> too little generality.  I've defenitely got the feeling that gdbarch
> gives us too little generality.

(Think yourself lucky.  At one stage people were arguing that the 
architecture and target vector should be combined into a single 
monolythic mess :-().

"regsets" could be made more independant of gdbarch by having its own 
local table and search methods:
	add_corefile_regset (bfd_arch, mach, size, name, ..., method);
	corefile_regset (bfd_arch, mach, name, size)
and a wrapper:
	gdbarch_corefile_regset (gdbarch, name, size)
	-> corefile_regset (gdbarch->bfd_arch, name, size)

Anyway, how were you thinking of doing things for the sparc?

Andrew