Re: dwarf_block_to_fb_offset() and 64-bit host

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Sun, 25 Jan 2015 06:52:08 +0100, Jonathan Larmour wrote:
> 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.

It is not really working.  It is just a secondary bug which will omit the
'id@entry' value to be read/displayed.  The primary bug is that reading the
value 'id@entry' errors.


> 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.

To find out whether there is or isn't a different value one has to read it
first.  Which for an unknown reason fails in your case.

If the id entry value was equal GDB would print:
	Breakpoint 2, fileio1_main (id=id@entry=0) at /.../fatfs1.c:431
which happens in neither of your case.

The primary problem is why GDB fails to read the address 0x9001917c.
It usually happens that GDB tries to read address like 0x19001917c or address
0xffffffff9001917c while then the error report
	return xstrprintf (_("Cannot access memory at address %s"),
			   paddress (gdbarch, memaddr));
strips the upper bits in paddress().

corefile.c:memory_error_message():
	s/paddress (gdbarch, memaddr)/core_addr_to_string (memaddr)/
may reveal that.



Jan