This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Pass gdbarch, not regset, to supply regset et.al.?
Date: Wed, 19 Nov 2003 18:28:29 -0500
From: Andrew Cagney <cagney@gnu.org>
> Date: Wed, 19 Nov 2003 14:37:58 -0500
> From: Andrew Cagney <ac131313@redhat.com>
>
> Mark,
>
> I'm wondering if it would be easier to explicitly pass the gdbarch
> instead of the regset to the regset function?
>
> I've thought about that, but I don't think so. I'd like to use these
> register sets even for cases where there's no gdbarch that we can
> easily get at. I'm thinking specifically about the *-nat.c modules
> where register sets are provided by ptrace(2), /proc, etc.
Sorry, I'm lost. ptrace and /proc both have an implied architecture, or
at least OS.
Yes they do, but:
* It's a bit of a hassle to get at the right architecture from within
a *-nat.c module.
* 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.
Mark