This is the mail archive of the
mailing list for the GDB project.
Re: RFC: Variables in blocks of registers
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Mark Kettenis <kettenis at chello dot nl>
- Cc: gdb at sources dot redhat dot com
- Date: Sat, 01 Feb 2003 10:48:32 -0500
- Subject: Re: RFC: Variables in blocks of registers
- References: <200302011448.h11EmCkP001176@elgar.kettenis.dyndns.org>
dwarf2 makes it possible to scatter a value across both memory and
registers. It's been proposed that the `struct value' be augmented with
something like `struct location' that knows how to find any sub
component of a value.
On my i386-unknown-freebsd4.7 system, various tests in
gdb.base/store.exp fail. The reason is related to the problem
described in tdep/214; register variables that don't fit in a single
variable. GDB assumes that such variables are stored in consecutive
registers (according to its own register numbering scheme), which
defenitely isn't what GCC uses on the i386.
I'm looking into the suggestion Daniel made in tdep/214; teaching GDB
about the order in which GCC allocates registers. There are several
* While GCC allocates its registers in a particular order right now,
and always allocates blocks of consecutive registers, there is no
guarantee that it will continue to do so.
* I have no idea what other compilers do. If GDB's register numbering
was chosen to match for example the System V compiler, teaching GDB
GCC's register ordering will cause regressions on system that use
it. We might play tricks with gcc_compiled of course.
Since AFAIK GDB's internal register ordering is still not decoupled
from the remote interface, I propose to add a new multi-arch function
"next_regnum" which returns the next register to look in based on the
register number passed to it as an argument.