This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Variables in blocks of registers

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
caveats though:

* 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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]