ret value of bfd_get_sign_extend_vma

ret value of bfd_get_sign_extend_vma

[Michael Mueller]

Can someone explain to me what the return value of function 
bfd_get_sign_extend_vma means? What the docu says is a mystery to me:

"Indicates if the target architecture "naturally" sign extends an 
address. Some architectures implicitly sign extend address values when 
they are converted to types larger than the size of an address. For 
instance, bfd_get_start_address() will return an address sign extended 
to fill a bfd_vma when this is the case."

How can an address have a sign? I think of an address as an unsigned 
quantity.

I found 2 uses of bfd_get_sign_extend_vma in gdb (I'm talking of solaris 
sparc 32 and 64 bit):

1) In dbxread.c, macro INTERNALIZE_SYMBOL

There it's used (among others) to read a negative offset of a local 
variable to the frame pointer. This should be sign extended.
See http://sources.redhat.com/ml/gdb-patches/2004-06/msg00433.html
and http://sources.redhat.com/ml/gdb/2001-08/msg00078.html

2) In dwarfread2.c

There it's used to read addresses which have no sign.

Re: ret value of bfd_get_sign_extend_vma

[Thiemo Seufer]

Michael Mueller wrote:
> Can someone explain to me what the return value of function 
> bfd_get_sign_extend_vma means? What the docu says is a mystery to me:
> 
> "Indicates if the target architecture "naturally" sign extends an 
> address. Some architectures implicitly sign extend address values when 
> they are converted to types larger than the size of an address. For 
> instance, bfd_get_start_address() will return an address sign extended 
> to fill a bfd_vma when this is the case."
> 
> How can an address have a sign? I think of an address as an unsigned 
> quantity.

E.g. MIPS addresses are signed. 64bit CPUs running 32bit Code
sign-extend the 32bit address. As a result, there's no need for
a 32bit-mode switch in the CPU, the 32bit address space is simply
the top/bottom 2GB of the 64bit address space.


Thiemo

RE: ret value of bfd_get_sign_extend_vma

[Dave Korn]

> -----Original Message-----
> From: binutils-owner On Behalf Of Michael Mueller
> Sent: 21 June 2004 16:35

> Can someone explain to me what the return value of function 
> bfd_get_sign_extend_vma means? What the docu says is a mystery to me:
> 
> "Indicates if the target architecture "naturally" sign extends an 
> address. Some architectures implicitly sign extend address 
> values when 
> they are converted to types larger than the size of an address. For 
> instance, bfd_get_start_address() will return an address sign 
> extended 
> to fill a bfd_vma when this is the case."
> 
> How can an address have a sign? I think of an address as an unsigned 
> quantity.

  Some systems that have a 32-bit address space also have 16-bit addressing
modes.  For instance m68k: if you wanted to load data register d0 from
memory address 4, you can write

     move.l    d0,$4

which generates an instruction with a 32-bit address field containing the
value 4, or you can write.

     move.l    d0,$4.w

which generates an instruction with only 16-bits in the address field.

  Naturally enough, a 16-bit address field isn't sufficient to address the
entire 32-bit address range.  Effectively it allows you access to 64k of
locations.  The only question is, which 64k of locations.

  On some systems, the full 32-bit address is generated by sticking 16 zeros
on the front of the 16-bit field.  So you can address ranges 0x00000000 to
0x0000ffff by using 16-bit addresses 0x0000 to 0xffff.

  But on other systems, and m68k is one, the cpu duplicates the topmost bit
of the 16-bit field into the upper (missing from the instruction) 16 address
bits.  So on these systems, 16-bit addresses 0x0000 to 0x7fff address 32-bit
range 0x00000000 to 0x00007fff, and 16-bit addresses 0x8000 to 0xffff
address 32-bit range 0xffff8000 to 0xffffffff.

  That is to say, on some systems the reduced addressing mode allows you to
access the lowest 64kb block at the bottom of memory; on others it allows
you to access both the lowest 32kb and the highest 32kb of the 32-bit range.

  So yes, addresses are basically unsigned; but the behaviour here is the
same as takes place in sign extension, and it's a reasonable analogy if you
think of negative addresses as referring to the top end of the memory map.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: ret value of bfd_get_sign_extend_vma

[Michael Mueller]

>   But on other systems, and m68k is one, the cpu duplicates the topmost bit
> of the 16-bit field into the upper (missing from the instruction) 16 address
> bits.  So on these systems, 16-bit addresses 0x0000 to 0x7fff address 32-bit
> range 0x00000000 to 0x00007fff, and 16-bit addresses 0x8000 to 0xffff
> address 32-bit range 0xffff8000 to 0xffffffff.

So that means that if I access a 16 bit range from 0x7ff0 to 0x8010 I 
access two noncontiguous pieces of memory. Funny.

But bfd_get_sign_extend_vma returns 0 on m68k doesn't it?

> 
>   That is to say, on some systems the reduced addressing mode allows you to
> access the lowest 64kb block at the bottom of memory; on others it allows
> you to access both the lowest 32kb and the highest 32kb of the 32-bit range.
> 
>   So yes, addresses are basically unsigned; but the behaviour here is the
> same as takes place in sign extension, and it's a reasonable analogy if you
> think of negative addresses as referring to the top end of the memory map.
> 
> 
>     cheers, 
>       DaveK


-- 

=== Michael Mueller ==================
Tel. + 49 8171 63600
Fax. + 49 8171 63615
Web: http://www.mm.kay-mueller.de
      http://www.planets.kay-mueller.de
======================================

Re: ret value of bfd_get_sign_extend_vma

[Andreas Schwab]

Michael Mueller <michael.mueller@kay-mueller.de> writes:

>>   But on other systems, and m68k is one, the cpu duplicates the topmost bit
>> of the 16-bit field into the upper (missing from the instruction) 16 address
>> bits.  So on these systems, 16-bit addresses 0x0000 to 0x7fff address 32-bit
>> range 0x00000000 to 0x00007fff, and 16-bit addresses 0x8000 to 0xffff
>> address 32-bit range 0xffff8000 to 0xffffffff.
>
> So that means that if I access a 16 bit range from 0x7ff0 to 0x8010 I
> access two noncontiguous pieces of memory. Funny.
>
> But bfd_get_sign_extend_vma returns 0 on m68k doesn't it?

There aren't actually true 16 bit addresses on m68k, it's just an
optimized way to address two memory regions in the 32 bit address space.
It does not make sense to speak of address 0x8010 when you mean
0xffff8010.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: ret value of bfd_get_sign_extend_vma

[Dave Korn]

> -----Original Message-----
> From: Michael Mueller  
> Sent: 22 June 2004 08:33

> > bits.  So on these systems, 16-bit addresses 0x0000 to 
> 0x7fff address 32-bit
> > range 0x00000000 to 0x00007fff, and 16-bit addresses 0x8000 
> to 0xffff
> > address 32-bit range 0xffff8000 to 0xffffffff.
> 
> So that means that if I access a 16 bit range from 0x7ff0 to 0x8010 I 
> access two noncontiguous pieces of memory. Funny.

  Well, you can't access a 16 byte range with a single instruction.  Each
word address you load from will be in either one range or the other.
There's just a boundary in there.  It's no funnier than the fact that if
you're using a signed 16-bit integer and you increment the positive number
32767 you get the negative number -32768; in fact it's exactly the same!
 
> But bfd_get_sign_extend_vma returns 0 on m68k doesn't it?

  I haven't actually checked; maybe that port handles the issue using some
different mechanism.



    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....