This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] solib-svr4.[hc]: Use gdbarch data mechanism...
- To: Kevin Buettner <kevinb at cygnus dot com>
- Subject: Re: [PATCH] solib-svr4.[hc]: Use gdbarch data mechanism...
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 26 Sep 2001 12:44:34 -0400
- Cc: gdb-patches at sources dot redhat dot com
- References: <1010926073025.ZM625@ocotillo.lan>
> The odd thing about it is that the gdbarch parameter is never used.
> Instead, it makes use of the fact that current_gdbarch has been set to
> the new architecture (and that gdbarch_data queries this new
> architecture). Perhaps this is nothing to worry about, but I had
> to stare at gdbarch.c for a while to convince myself that it would
> work as I wanted it to. I'd feel better about the whole thing if
> there were a version of gdbarch_data() which would take a
> struct gdbarch * as an argument. Maybe something like the following?
You're correct. It was a compromise. All the architecture methods
should be explicitly parameterised with their architecture. That,
however was considered secondary to just getting everything into the
architecture vector.
It is probably time to start changing though. gdbarch_data() is
probably a good point to start. It will mean that ``current_gdbarch''
is going to be refered to everywhere for a while.
This is very similar to the frame problem where there is going to be a
transition period.
Andrew