This is the mail archive of the gdb-prs@sources.redhat.com 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: exp/1811: "set var x = y" doesn't work properly if sizeof(x) < sizeof(register)


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


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