public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Re: 8-byte register values on a 32-bit machine
@ 2003-03-02  6:52 Michael Elizabeth Chastain
  2003-03-02  9:35 ` Stephane Carrez
  0 siblings, 1 reply; 32+ messages in thread
From: Michael Elizabeth Chastain @ 2003-03-02  6:52 UTC (permalink / raw)
  To: kettenis; +Cc: brobecker, gdb

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@mvista.com>

  Based on a patch from Daniel Berlin (dberlin@dberlin.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

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: 8-byte register values on a 32-bit machine
@ 2003-03-14 16:27 Michael Elizabeth Chastain
  0 siblings, 0 replies; 32+ messages in thread
From: Michael Elizabeth Chastain @ 2003-03-14 16:27 UTC (permalink / raw)
  To: ac131313; +Cc: brobecker, drow, gdb, kettenis, stcarrez

andrew> Right, so it can't be assumed that `the general case of
andrew> 2-word structs in 5.3 was broken'.

It can't be assumed that they worked in 5.3, either.

In gdb HEAD, last time I looked, the dwarf2 code fetched only one word
from the target.  So with gdb HEAD I believe they are broken on ALL
architectures, unless Daniel has fixed them in the past week.

Michael C

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: 8-byte register values on a 32-bit machine
@ 2003-03-13  4:18 Michael Elizabeth Chastain
  2003-03-13 17:05 ` Andrew Cagney
  0 siblings, 1 reply; 32+ messages in thread
From: Michael Elizabeth Chastain @ 2003-03-13  4:18 UTC (permalink / raw)
  To: ac131313; +Cc: brobecker, drow, gdb, kettenis, stcarrez

mec> The general case of 2-word structures in 5.3 was broken.  That is to say,
mec> my simple test program (attached to the PR) fails with both 5.3 and HEAD.

ac> I386 or general?  To the best of my knowledge, structs worked on 
ac> non-i386 architectures.

Native i686-pc-linux-gnu.

I just tested on native sparc-sun-solaris2.7, but the only compiler
I have, gcc 3.2.2, does not put the 2-word structure into registers.

Michael C

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: 8-byte register values on a 32-bit machine
@ 2003-03-12 19:09 Michael Elizabeth Chastain
  2003-03-12 20:47 ` Andrew Cagney
  0 siblings, 1 reply; 32+ messages in thread
From: Michael Elizabeth Chastain @ 2003-03-12 19:09 UTC (permalink / raw)
  To: ac131313, drow; +Cc: brobecker, gdb, kettenis, stcarrez

The general case of 2-word structures in 5.3 was broken.  That is to say,
my simple test program (attached to the PR) fails with both 5.3 and HEAD.

I would like to re-suggest my idea that gdb simply print "<unknown>"
or something for all the words beyond the first word in a register
variable.  But I'll back whatever Daniel thinks is right.

Michael C

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: 8-byte register values on a 32-bit machine
@ 2003-03-02 16:59 Michael Elizabeth Chastain
  2003-03-12 15:35 ` Andrew Cagney
  0 siblings, 1 reply; 32+ messages in thread
From: Michael Elizabeth Chastain @ 2003-03-02 16:59 UTC (permalink / raw)
  To: drow, stcarrez; +Cc: brobecker, gdb, kettenis

Okay, I got some sleep and drank some tea and stuff.  I'm a bit more
calm now.  :)

I filed a proper PR, so that Daniel J (or anybody) can flow it into
their TODO list.  Daniel said he has several things to do in this code
so I want to get in line properly.

I did mark it severity=critical because gdb prints incorrect values, and
priority=high because Stephane C says that it happens a lot on the HC11.

gdb 5.3 has a different bug in the same area, so this is only sort-of a
regression.  The specific program store.exp in the test suite regressed
between 2003-02-15 and 2003-02-23, but my test program r8.c in the PR is
busted with both gdb 5.3 and gdb 2003-03-01-cvs.

Michael C

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: 8-byte register values on a 32-bit machine
@ 2003-03-01 20:57 Michael Elizabeth Chastain
  2003-03-01 22:46 ` Mark Kettenis
  0 siblings, 1 reply; 32+ messages in thread
From: Michael Elizabeth Chastain @ 2003-03-01 20:57 UTC (permalink / raw)
  To: brobecker, kettenis; +Cc: gdb

For concreteness, suppose that the user has a structure with
two integers in it, and sizeof(int) is the natural register size
(which of course has been the design principle for C for decades).

  struct point
  {
    int x;
    int y;
  };

  struct point p1 = { 1234, 5678 };

Everybody's favorite output is:

  (gdb) print p1
  $1 = {1234, 5678}

Right now gdb can print lies:

  (gdb) print p1
  $1 = {1234, -8675309}

Incorrect data is much worse than no data at all.  Instead of iterating
over registers, I would like gdb to print:

  (gdb) print p1
  $1 = {1234, <unknown>}

I'm not stuck on "<unknown>".  It can be any string which indicates the
debugger can't tell the user what's in p1.y.

The heinous part is that gdb *knows* it is pulling some register value out of
its ass for p1.y.  I understand that on some targets, gcc and gdb might agree
on register number allocation (ignore for the moment that there are other
compilers besides gcc).  Okay, for targets where we have a guarantee about
that, then enable sequential register access.  But i686-pc-linux-gnu is
definitely not such a target.

Somewhat worse is:

  (gdb) print p1
  $1 = <unknown>

If the compiler tells us that an 8-byte variable is in a 4-byte register,
I feel comfortable printing the first 4 bytes.  But I would actually
printing no values to printing incorrect values.

If a debug format has enough information to print {1234, 5678},
that's great.  And we should ask gcc to give us that much information
in all the formats we can get to.  If we're lucky, then stabs+ will
become obsolete faster than people start seeing more multi-register
variables.  :)

Michael C

^ permalink raw reply	[flat|nested] 32+ messages in thread
* 8-byte register values on a 32-bit machine
@ 2003-02-24  2:36 Michael Elizabeth Chastain
  2003-03-01 13:35 ` Mark Kettenis
  0 siblings, 1 reply; 32+ messages in thread
From: Michael Elizabeth Chastain @ 2003-02-24  2:36 UTC (permalink / raw)
  To: drow, gdb

I saw a regression in gdb.base/store.exp this week:

  gdb.base/store.exp: new check struct 4
    PASS -> FAIL

This happens with gcc 2.95.3 -gdwarf-2.

This happens because gcc 2.95.3 puts an 8-byte variable into a pair of
4-byte registers.  (gcc 3.2.2 puts the variable into memory so the
problem never arises -- but I bet it will come back for things like
FORTRAN complex numbers, which are very natural for register pairs).

It happened this particular week because the old dwarf-2 code had some
code to handle multi-register variables, although the code doesn't
appear to work for me.  The new dwarf-2 code just completely spaces
in the case of multi-register variables.

We need to figure out what the right symbol table information is for
multi-register variables.  If gcc is emitting good symbol table
information, gdb can do its job, and I can write a test case for it.

But I suspect that gcc 2.95.3 tells us about just one register and that
we can't win.  But gdb can at least say "hmmm, you are trying to print 8
bytes from reg0, I can't do that", rather than print 4 bytes of correct
information and 4 bytes of rat poison.  I think that would be acceptable
support for 2.95.3.

I filed a PR and I'll attach some executables to it.

Michael C

^ permalink raw reply	[flat|nested] 32+ messages in thread
end of thread, other threads:[~2003-03-14 16:27 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-02  6:52 8-byte register values on a 32-bit machine Michael Elizabeth Chastain
2003-03-02  9:35 ` Stephane Carrez
2003-03-03  4:50   ` Daniel Jacobowitz
  -- strict thread matches above, loose matches on Subject: below --
2003-03-14 16:27 Michael Elizabeth Chastain
2003-03-13  4:18 Michael Elizabeth Chastain
2003-03-13 17:05 ` Andrew Cagney
2003-03-12 19:09 Michael Elizabeth Chastain
2003-03-12 20:47 ` Andrew Cagney
2003-03-02 16:59 Michael Elizabeth Chastain
2003-03-12 15:35 ` Andrew Cagney
2003-03-12 15:51   ` Daniel Jacobowitz
2003-03-12 16:57     ` Andrew Cagney
2003-03-12 17:01       ` Daniel Jacobowitz
2003-03-12 18:15         ` Andrew Cagney
2003-03-12 18:29     ` Andrew Cagney
2003-03-12 18:35       ` Daniel Jacobowitz
2003-03-12 18:38         ` Andrew Cagney
2003-03-12 18:48         ` Paul Koning
2003-03-12 19:00           ` Daniel Jacobowitz
2003-03-12 21:04             ` Andrew Cagney
2003-03-12 20:06               ` Daniel Jacobowitz
2003-03-01 20:57 Michael Elizabeth Chastain
2003-03-01 22:46 ` Mark Kettenis
2003-02-24  2:36 Michael Elizabeth Chastain
2003-03-01 13:35 ` Mark Kettenis
2003-03-01 20:33   ` Joel Brobecker
2003-03-01 22:38     ` Mark Kettenis
2003-03-01 23:41       ` Andrew Cagney
2003-03-02  0:28         ` Daniel Jacobowitz
2003-03-03 11:26           ` Richard Earnshaw
2003-03-03 11:52             ` Keith Walker
2003-03-01 23:39     ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).