Re: dwarf_block_to_fb_offset() and 64-bit host

Thanks for all the replies, sorry for the delay in getting back but I
haven't been able to work full time on this...

On 25/01/15 08:27, Jan Kratochvil wrote:
> 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.

After investigation, the reason the read of id@entry failed was because
the remote target has provided a memory region map, and the requested
stack address to read was 0xffffffff90019160, instead of 0x90019160,
therefore lying outside of the permitted memory map, so GDB never even
attempted to read from the target. The read of the value came from a call
to dwarf2_frame_cache() which calls dwarf2-frame.c:read_reg() which uses
unpack_long() which returns a LONGEST which, despite being converted to
CORE_ADDR on return, has been sign extended.

BUT...

what I intended to say in my previous mail but accidentally missed was
that this is from GDB 7.6.2. I see that the code in 7.8.2 has changed
substantially, now using read_addr_from_reg() which behaves more
appropriately for addresses.

Indeed, now I've switched to 7.8.2 everything _appears_ to outwardly work
okay. However, it now works in the same way that the 32-bit version works,
and from the comments in this thread, could there still be a lurking but
hidden problem here, because there is still a negative fb_offset of -28?
I've tried a variety of different functions and programs, on different ARM
targets, and every time fb_offset is negative when reading the frame args.
So I have to query whether a negative fb_offset really is a problem.

Just in case I was missing something, I thought I would follow Doug Evans'
suggestion of changing fb_offset_return to use LONGEST, but not very
surprisingly that didn't help the negative fb_offset (Doug's suggestion
really being about the discrepancy between 32- and 64-bit host behaviour).

Jifl
-- 

Besuchen Sie uns vom 24-26 Feb auf der Embedded World 2015, Stand 4-161
Visit us at Embedded World 2015, Nürnberg-Germany, Stand 4-161, 24-26 Feb

eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine