Re: 8-byte register values on a 32-bit machine

[Michael Elizabeth Chastain <mec at shout dot net>]

mec> I understand that on some targets, gcc and gdb might agree on register
mec> number allocation (ignore for the moment that there are other compilers
mec> besides gcc).  Okay, for targets where we have a guarantee about that,
mec> then enable sequential register access.  But i686-pc-linux-gnu is
mec> definitely not such a target.

mark> I don't agree with the defenitely here.  GCC has been allocating the
mark> registers in a well determined order for at least 10 years now.

Ah, yeah, I am saying that gcc and gdb disagree on the register
number ordering, and you are saying that gcc has a well determined
order -- so in principle gdb could know that order and follow it.
I think both statements are true.

This test worked for months and then regressed recently.  gdb's code
recently changed from "iterate over some registers" (which worked for
this test case, at least, but is not guaranteed to work all the time).
Then this patch happened:

  2003-02-21  Daniel Jacobowitz  <drow at mvista dot com>

  Based on a patch from Daniel Berlin (dberlin at dberlin dot org)
  ...
  * dwarf2expr.c, dwarf2expr.h, dwarf2loc.c, dwarf2loc.h: New files.
  ...

Before this patch, the dwarf2 reader would mark these as LOC_REGISTER
and value_from_register would loop over the # of registers that are
needed.  This is the case we are talking about, where gdb and the
compiler in use might or might not match on the register assignments.

After this patch, (that is, in today's gdb), the dwarf2 reader marks the
multi-register expression as LOC_COMPUTED.  Then
dwarf2_evaluate_loc_desc calls store_unsigned_integer just once, *no
matter how large the size is*.  I've seen this happen by debugging gdb
running on my test program (build testsuite/gdb.base/store.exp with gcc
2.95.3 -gdwarf-2).  gdb doesn't even try to read any other registers.
So if the location is "register %eax, size 8", gdb does not even look in
%edx.  I don't know exactly where gdb gets bytes 4-7 of the data.  I
%suspect it's just using uninitialized buffer contents.  That's what I
%really meant about gdb pulling values "out of its ass".

Also I apologize for that phrase.  I think it's accurate for what gdb is
doing right now with, but I didn't share that knowledge about
dwarf2_evaluate_loc_desc, and it's kind of inflammatory to say that for
register orders.  Plus it's disrespectful to the developers which is the
real problem.  Obviously this is work in progress and that's what CVS is
for, and that's what regression testing is for.

Anyways, I think there are two problems here:

(1) dwarf2_evaluate_loc_desc is getting called with ctx->in_reg=true
    and size=8.  I need to provide an actual test executable to show
    this happening.  When this happens, dwarf2_evaluate_loc_desc just
    reads *1* register.  This is definitely wrong (if my description
    of gdb's behavior is accurate).

(2) We have to decide what gdb will do in various cases.  As I've
    mentioned, I'm hostile to the idea of gdb intuiting the register
    order.  If there is no list of registers is not as long as the
    data size then I would rather that gdb print "<unknown>" for the
    unknown ones.  But I recognize that's up to the symtab
    maintainers to decide.  Thanks for listening to my input.

Michael C