64bit bfd_vma vs 32bit address space in linker

64bit bfd_vma vs 32bit address space in linker

[Andreas Schwab]

What is the expected behaviour of the linker when dot advances past the
32 bit address space and bfd_vma is 64 bits?  Is this undefined, or
should the result wrap around as if bfd_vma is only 32 bits?  Note the
address of .text in the linker map below.

$ objdump --info
BFD header file version 2.13.90.0.18 20030121 (SuSE Linux)
elf32-i386
 (header little endian, data little endian)
  i386
a.out-i386-linux
 (header little endian, data little endian)
  i386
efi-app-ia32
 (header little endian, data little endian)
  i386
elf32-little
 (header little endian, data little endian)
  i386
elf32-big
 (header big endian, data big endian)
  i386
elf64-x86-64
 (header little endian, data little endian)
  i386
elf64-little
 (header little endian, data little endian)
  i386
elf64-big
 (header big endian, data big endian)
  i386
srec
 (header endianness unknown, data endianness unknown)
  i386
symbolsrec
 (header endianness unknown, data endianness unknown)
  i386
tekhex
 (header endianness unknown, data endianness unknown)
  i386
binary
 (header endianness unknown, data endianness unknown)
  i386
ihex
 (header endianness unknown, data endianness unknown)
  i386
trad-core
 (header endianness unknown, data endianness unknown)

               elf32-i386 a.out-i386-linux efi-app-ia32 elf32-little elf32-big 
          i386 elf32-i386 a.out-i386-linux efi-app-ia32 elf32-little elf32-big 

               elf64-x86-64 elf64-little elf64-big srec symbolsrec tekhex 
          i386 elf64-x86-64 elf64-little elf64-big srec symbolsrec tekhex 

               binary ihex trad-core 
          i386 binary ihex --------- 
$ cat rom.s
        .section ".rom.text"
        .code16
        .globl  _start
_start:
        cli

        .section ".reset"
        .code16
.globl  reset_vector
reset_vector:
        jmp     _start_offset
$ cat rom.lds
OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
OUTPUT_ARCH(i386)

ENTRY(_start)

_RAMBASE = 0x4000;
_ROMBASE = 0xffff0000;
_start_offset = _start & 0xffff;

TARGET(binary)
SECTIONS
{
        . = _ROMBASE;

        .rom . : {
                _rom = .;
                *(.rom.text);
                *(.rom.data);
                . = ALIGN(16);
                _erom = .;
        }

        /DISCARD/ : {
                *(.comment)
                *(.note)
        }
}

SECTIONS {
        _ROMTOP = (_ROMBASE >= 0xffff0000)? 0xfffffff0 : 0xffff0;
        . = _ROMTOP;
        .reset . : {
                *(.reset)
                . = 15 ;
                BYTE(0x00);
        } 
}
$ as rom.s -o rom.o
$ ld rom.o -T rom.lds -M
rom.o(.reset+0x1): In function `reset_vector':
: relocation truncated to fit: R_386_PC16 _start_offset

Memory Configuration

Name             Origin             Length             Attributes
*default*        0x0000000000000000 0xffffffffffffffff

Linker script and memory map

LOAD rom.o
                0x0000000000004000                _RAMBASE = 0x4000
                0x00000000ffff0000                _ROMBASE = 0xffff0000
                0x0000000000000000                _start_offset = (_start & 0xffff)
TARGET(binary)
                0x00000000ffff0000                . = _ROMBASE

.rom            0x00000000ffff0000       0x10
                0x00000000ffff0000                _rom = .
 *(.rom.text)
 .rom.text      0x00000000ffff0000        0x1 rom.o
                0x00000000ffff0000                _start
 *(.rom.data)
                0x00000000ffff0010                . = ALIGN (0x10)
 *fill*         0x00000000ffff0001 0x10000000f 00
                0x00000000ffff0010                _erom = .

/DISCARD/
 *(.comment)
 *(.note)
                0x00000000fffffff0                _ROMTOP = (_ROMBASE >= 0xffff0000)?0xfffffff0:0xffff0
                0x00000000fffffff0                . = _ROMTOP

.reset          0x00000000fffffff0       0x10
 *(.reset)
 .reset         0x00000000fffffff0        0x3 rom.o
                0x00000000fffffff0                reset_vector
                0x00000000ffffffff                . = 0xf
 *fill*         0x00000000fffffff3 0x10000000c 00
                0x00000000ffffffff        0x1 BYTE 0x0
OUTPUT(a.out elf32-i386)

.text           0x0000000100000000        0x0

.data           0x0000000100000000        0x0

.bss            0x0000000100000000        0x0


Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 64bit bfd_vma vs 32bit address space in linker

[Alan Modra]

On Fri, Apr 04, 2003 at 05:46:14PM +0200, Andreas Schwab wrote:
> What is the expected behaviour of the linker when dot advances past the
> 32 bit address space and bfd_vma is 64 bits?  Is this undefined, or
> should the result wrap around as if bfd_vma is only 32 bits?

Ideally, none of the binutils should produce different output when
bfd_vma changes size to larger than necessary.

>  Note the
> address of .text in the linker map below.

Something needs to take note of bfd_arch_info_type.bits_per_address.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: 64bit bfd_vma vs 32bit address space in linker

[Alexandre Oliva]

On Apr  7, 2003, Alan Modra <amodra@bigpond.net.au> wrote:

> Something needs to take note of bfd_arch_info_type.bits_per_address.

bits_per_address is not necessarily the right choice.  In fact, it
often isn't.  See for example the patch I posted earlier today, that
addresses one situation in which the arch's bits_per_address is the
wrong choice to determine the pointer width.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: 64bit bfd_vma vs 32bit address space in linker

[Alan Modra]

On Mon, Apr 07, 2003 at 11:47:19PM -0300, Alexandre Oliva wrote:
> On Apr  7, 2003, Alan Modra <amodra@bigpond.net.au> wrote:
> 
> > Something needs to take note of bfd_arch_info_type.bits_per_address.
> 
> bits_per_address is not necessarily the right choice.

Without looking in detail at the code, I believe that bits_per_address
is exactly the right thing to use to implement the (currently missing
when BFD64) linker address wrap.  See uses of bits_per_address in
bfd/relocs.c.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: 64bit bfd_vma vs 32bit address space in linker

[Alexandre Oliva]

On Apr  8, 2003, Alan Modra <amodra@bigpond.net.au> wrote:

> Without looking in detail at the code, I believe that bits_per_address
> is exactly the right thing to use to implement the (currently missing
> when BFD64) linker address wrap.

I'm afraid it isn't.  Consider 32-bit code (say o32) running on a
64-bit architecture (MIPS III).  You do want to truncate addresses to
32 bits, since the ABI mandates 32-bit addresses, but bits_per_address
will return 64.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: 64bit bfd_vma vs 32bit address space in linker

[Alan Modra]

On Tue, Apr 08, 2003 at 03:25:34AM -0300, Alexandre Oliva wrote:
> On Apr  8, 2003, Alan Modra <amodra@bigpond.net.au> wrote:
> 
> > Without looking in detail at the code, I believe that bits_per_address
> > is exactly the right thing to use to implement the (currently missing
> > when BFD64) linker address wrap.
> 
> I'm afraid it isn't.  Consider 32-bit code (say o32) running on a
> 64-bit architecture (MIPS III).  You do want to truncate addresses to
> 32 bits, since the ABI mandates 32-bit addresses, but bits_per_address
> will return 64.

So why isn't bits_per_address == 32 if the ABI says addresses are
32-bit?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: 64bit bfd_vma vs 32bit address space in linker

[Thiemo Seufer]

Alexandre Oliva wrote:
> On Apr  8, 2003, Alan Modra <amodra@bigpond.net.au> wrote:
> 
> > Without looking in detail at the code, I believe that bits_per_address
> > is exactly the right thing to use to implement the (currently missing
> > when BFD64) linker address wrap.
> 
> I'm afraid it isn't.  Consider 32-bit code (say o32) running on a
> 64-bit architecture (MIPS III).  You do want to truncate addresses to
> 32 bits, since the ABI mandates 32-bit addresses, but bits_per_address
> will return 64.

Looks like MIPS gets it wrong in cpu-mips.c. Other architectures (ia64)
use different bfd_mach_* vectors for this purpose.


Thiemo

Re: 64bit bfd_vma vs 32bit address space in linker

[Alexandre Oliva]

On Apr  8, 2003, Alan Modra <amodra@bigpond.net.au> wrote:

> So why isn't bits_per_address == 32 if the ABI says addresses are
> 32-bit?

Because bits_per_address is a property of the architecture.  The same
architecture can run programs that follow several different ABIs, some
of them with 32-bit addresses, some with 64-bit addresses.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: 64bit bfd_vma vs 32bit address space in linker

[Andreas Jaeger]

Alan Modra <amodra@bigpond.net.au> writes:

> On Tue, Apr 08, 2003 at 03:25:34AM -0300, Alexandre Oliva wrote:
>> On Apr  8, 2003, Alan Modra <amodra@bigpond.net.au> wrote:
>> 
>> > Without looking in detail at the code, I believe that bits_per_address
>> > is exactly the right thing to use to implement the (currently missing
>> > when BFD64) linker address wrap.
>> 
>> I'm afraid it isn't.  Consider 32-bit code (say o32) running on a
>> 64-bit architecture (MIPS III).  You do want to truncate addresses to
>> 32 bits, since the ABI mandates 32-bit addresses, but bits_per_address
>> will return 64.
>
> So why isn't bits_per_address == 32 if the ABI says addresses are
> 32-bit?

It is for i386/x86-64 - but where do we need to add the "currently
missing linker address wrap"?  Is this something that has to be added
for each CPU?  Or should it be added to ld?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: 64bit bfd_vma vs 32bit address space in linker

[Alan Modra]

On Tue, Apr 08, 2003 at 09:28:13AM +0200, Andreas Jaeger wrote:
> but where do we need to add the "currently
> missing linker address wrap"?

Everywhere.  The primary change is to mask places that adjust "dot" in
ldlang.c and ldexp.c, but this change will trickle down into all
expression evaluation code.  eg. an address difference on a 32 bit
target like

 0 - 0xffff0000

should evaluate to 0x10000 regardless of whether bfd_vma is 32-bit or
64-bit.  Perhaps you see why I merely acknowledge the bug and don't
jump in with a patch.  :-)

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: 64bit bfd_vma vs 32bit address space in linker

[Alan Modra]

On Tue, Apr 08, 2003 at 03:55:27AM -0300, Alexandre Oliva wrote:
> On Apr  8, 2003, Alan Modra <amodra@bigpond.net.au> wrote:
> 
> > So why isn't bits_per_address == 32 if the ABI says addresses are
> > 32-bit?
> 
> Because bits_per_address is a property of the architecture.  The same
> architecture can run programs that follow several different ABIs, some
> of them with 32-bit addresses, some with 64-bit addresses.

Hmm, let's rename bfd_arch_info_type to bfd_arch_abi_info_type.  ;-)

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: 64bit bfd_vma vs 32bit address space in linker

[Alexandre Oliva]

On Apr  8, 2003, Alan Modra <amodra@bigpond.net.au> wrote:

> Hmm, let's rename bfd_arch_info_type to bfd_arch_abi_info_type.  ;-)

Works for me :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer