This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: exp/1811: "set var x = y" doesn't work properly if sizeof(x) < sizeof(register)
- From: Randolph Chung <randolph at tausq dot org>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 16 Nov 2004 02:38:00 -0000
- Subject: Re: exp/1811: "set var x = y" doesn't work properly if sizeof(x) < sizeof(register)
- Reply-to: Randolph Chung <randolph at tausq dot org>
The following reply was made to PR exp/1811; it has been noted by GNATS.
From: Randolph Chung <randolph@tausq.org>
To: gdb-gnats@sources.redhat.com
Cc:
Subject: Re: exp/1811: "set var x = y" doesn't work properly if sizeof(x) < sizeof(register)
Date: Mon, 15 Nov 2004 18:34:12 -0800
It occured to me when I was driving home that my description of the
problem is not quite correct.
The problem at probably actually an endian one.
In the example posted, where a variable is in a register, we store in
the right end of the register. In this case, the variable setting logic
is correct.
In the case where gcc does not assign a "register" variable to a
register, but instead writes it to a stack slot, we don't handle it
correctly:
(gdb) print &l
$37 = (charest *) 0xbff003c8 ""
(gdb) x/x &l
0xbff003c8: 0x00000001
(gdb) set var l = 10
(gdb) x/x &l
0xbff003c8: 0x0a000001
notice that the 10 got written to the MSB of the register (hppa is
big-endian). Is this actually a problem with the compiler? the dwarf
info for this variable is:
<2><cca>: Abbrev Number: 6 (DW_TAG_variable)
DW_AT_name : l
DW_AT_decl_file : 1
DW_AT_decl_line : 69
DW_AT_type : <a3c>
DW_AT_location : 2 byte block: 91 8 (DW_OP_fbreg: 8)
should it actually say DW_OP_fbreg 11 instead?
Anyway, the fact that "register" doesn't force variables to registers
break this test in other ways.... for example, if l is in a stack slot,
and the target uses a return register to return the result, then
immediately following the call to add_charest (), the desired result may
be in the return register instead of in l's stack slot, so printing l
at that point will return the wrong value. Even if l were in a register,
i suppose the compiler can still do an extra register copy after
add_charest () returns, which will break the test.
randolph