This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] [17/17] Get rid of current_gdbarch in go32-nat.c
On Wed, Oct 24, 2007 at 06:04:58AM +0200, Eli Zaretskii wrote:
> > Date: Tue, 23 Oct 2007 17:15:28 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Markus Deuling <deuling@de.ibm.com>, gdb-patches@sourceware.org,
> > uweigand@de.ibm.com
> >
> > Even a single-architecture port may have more than one
> > current_gdbarch. A gdbarch is fine-grained and e.g. different
> > executables can lead to different gdbarches. So a GDB for DJGPP which
> > supported debugging two programs at once might need more than one
> > "current" gdbarch.
>
> Can you please describe an example where this is possible? Perhaps I
> don't understand what is gdbarch, but I think this is impossible with
> DJGPP.
A gdbarch includes lots of information. Some examples:
- What registers are available, including pseudo-registers and
emulated registers. E.g., if DJGPP supports running binaries
with and without MMX support available more than one gdbarch might
be needed.
- The sizes of basic types. E.g., if some versions of DJGPP used
a 64-bit long double and other versions used an 80-bit long double.
This transition seems to happen on many platforms at least once.
- Mapping of debug info numbers to register numbers. E.g., if two
compilers used different numbers this might be handled by setting
a different function pointer in the gdbarch depending on the loaded
binary.
Maybe none of these apply now, but they may someday.
--
Daniel Jacobowitz
CodeSourcery