Re: dwarf_block_to_fb_offset() and 64-bit host

Jonathan Larmour <[email protected]> writes:
> Hi folks,
>
> I've been looking at a problem on a remote Cortex-M target, which notably
> happens to have a somewhat atypical property of using an address space of
> 0x9xxxxxxx - in other words, addresses will have the top bit set.
>
> When debugging, there is a problem with a GDB built for a 64-bit host,
> versus one built for 32-bit, all from exactly the same source base. It
> manifests with this sort of issue with a 64-bit hosted GDB:
>
> Breakpoint 2, fileio1_main (id=0, id@entry=<error reading variable: Cannot
> access memory at address 0x9001917c>)
>     at /.../fatfs1.c:431
>
> The cited address is perfectly valid and readable. Whereas on a 32-bit GDB:
> Breakpoint 2, fileio1_main (id=0) at /.../fatfs1.c:431
>
> I have tracked down where the 32-bit and 64-bit builds of GDB diverge in
> behaviour and it's in dwarf2expr.c's dwarf_block_to_fb_offset():
>
> int
> dwarf_block_to_fb_offset (const gdb_byte *buf, const gdb_byte *buf_end,
>                           CORE_ADDR *fb_offset_return)
> {
>   int64_t fb_offset;
> [snip]
>   buf++;
>
>   buf = gdb_read_sleb128 (buf, buf_end, &fb_offset);
>   if (buf == NULL)
>     return 0;
>   *fb_offset_return = fb_offset;
>   if (buf != buf_end || fb_offset != (LONGEST) *fb_offset_return)
>     return 0;
>
>   return 1;
> }
>
> In the 32-bit (working) build, in one failing example, fb_offset ends up
> as -28, whereas *fb_offset_return is 0xffffffe4 - this is because
> CORE_ADDR is an *unsigned* 32-bit type (due to bfd_vma). But LONGEST is a
> signed long long - 64-bits - so the comparison between fb_offset and
> *fb_offset_return ends up comparing -28 and 4294967268. So 0 is returned.
>
> In the 64-bit (buggy) build, fb_offset is still -28 but *fb_offset_return
> is 0xffffffffffffffe4 (CORE_ADDR now being an unsigned 64-bit type), which
> when cast to LONGEST (which is signed) is still -28. Therefore 1 is
> returned. This later results in read_frame_arg()'s call to
> ops->read_variable_at_entry incorrectly believing there is a different
> value of the variable on entry.
>
> I'm unsure about where the bug really lies. I'm not familiar enough with
> Dwarf, but I have to wonder why there's the test for "fb_offset !=
> (LONGEST) *fb_offset_return" in the first place.
>
> Any help/advice from anyone with Dwarf experience would be welcome, thanks.

Hi.
It would not be unexpected if there are multiple bugs here.

E.g., if the cited address is valid, why is there an error reading it?
[and if gdb could successfully read it would it have noticed that
the two values are the same and thus you'd get the same output as
in the 32-bit case]

Here's where fb_offset originates from:

gdbtypes.h:

	union call_site_parameter_u
	  {
	    /* * DW_TAG_formal_parameter's DW_AT_location's DW_OP_regX
	       as DWARF register number, for register passed
	       parameters.  */

	    int dwarf_reg;

	    /* * Offset from the callee's frame base, for stack passed
	       parameters.  This equals offset from the caller's stack
	       pointer.  */

	    CORE_ADDR fb_offset;

	    /* * Offset relative to the start of this PER_CU to
	       DW_TAG_formal_parameter which is referenced by both
	       caller and the callee.  */

	    cu_offset param_offset;
	  }
	u;

I guess the first question is: Is an fb_offset of -28 valid?
i.e., is a negative value valid?
[Certainly a negative value is valid for DW_OP_fbreg.
But is it valid in this context?  Dunno off hand.]

Also, I can imagine that the "fb_offset != (LONGEST) *fb_offset_return"
test is to verify there's no loss in precision in the saved value.
So while dwarf_block_to_fb_offset is returning 1 in the "buggy"
case it seems to me that that could be the correct result.
[Hence wondering if there's another bug.]

I'm curious what would happen if you changed
"CORE_ADDR fb_offset" to "LONGEST fb_offset"
and updated all the affected pieces,
including changing the signature of dwarf_block_to_fb_offset to

int
dwarf_block_to_fb_offset (const gdb_byte *buf, const gdb_byte *buf_end,
			  LONGEST *fb_offset_return)