* 64bit bfd_vma vs 32bit address space in linker
@ 2003-04-04 15:46 Andreas Schwab
2003-04-08 0:58 ` Alan Modra
0 siblings, 1 reply; 12+ messages in thread
From: Andreas Schwab @ 2003-04-04 15:46 UTC (permalink / raw)
To: binutils; +Cc: Stefan Reinauer
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."
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 64bit bfd_vma vs 32bit address space in linker
2003-04-04 15:46 64bit bfd_vma vs 32bit address space in linker Andreas Schwab
@ 2003-04-08 0:58 ` Alan Modra
2003-04-08 2:47 ` Alexandre Oliva
0 siblings, 1 reply; 12+ messages in thread
From: Alan Modra @ 2003-04-08 0:58 UTC (permalink / raw)
To: Andreas Schwab; +Cc: binutils, Stefan Reinauer
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 64bit bfd_vma vs 32bit address space in linker
2003-04-08 0:58 ` Alan Modra
@ 2003-04-08 2:47 ` Alexandre Oliva
2003-04-08 5:17 ` Alan Modra
0 siblings, 1 reply; 12+ messages in thread
From: Alexandre Oliva @ 2003-04-08 2:47 UTC (permalink / raw)
To: Alan Modra; +Cc: Andreas Schwab, binutils, Stefan Reinauer
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 64bit bfd_vma vs 32bit address space in linker
2003-04-08 2:47 ` Alexandre Oliva
@ 2003-04-08 5:17 ` Alan Modra
2003-04-08 6:25 ` Alexandre Oliva
0 siblings, 1 reply; 12+ messages in thread
From: Alan Modra @ 2003-04-08 5:17 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Andreas Schwab, binutils, Stefan Reinauer
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 64bit bfd_vma vs 32bit address space in linker
2003-04-08 5:17 ` Alan Modra
@ 2003-04-08 6:25 ` Alexandre Oliva
2003-04-08 6:45 ` Alan Modra
2003-04-08 6:53 ` Thiemo Seufer
0 siblings, 2 replies; 12+ messages in thread
From: Alexandre Oliva @ 2003-04-08 6:25 UTC (permalink / raw)
To: Alan Modra; +Cc: Andreas Schwab, binutils, Stefan Reinauer
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 64bit bfd_vma vs 32bit address space in linker
2003-04-08 6:25 ` Alexandre Oliva
@ 2003-04-08 6:45 ` Alan Modra
2003-04-08 6:55 ` Alexandre Oliva
2003-04-08 7:28 ` Andreas Jaeger
2003-04-08 6:53 ` Thiemo Seufer
1 sibling, 2 replies; 12+ messages in thread
From: Alan Modra @ 2003-04-08 6:45 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Andreas Schwab, binutils, Stefan Reinauer
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 64bit bfd_vma vs 32bit address space in linker
2003-04-08 6:45 ` Alan Modra
@ 2003-04-08 6:55 ` Alexandre Oliva
2003-04-08 9:49 ` Alan Modra
2003-04-08 7:28 ` Andreas Jaeger
1 sibling, 1 reply; 12+ messages in thread
From: Alexandre Oliva @ 2003-04-08 6:55 UTC (permalink / raw)
To: Alan Modra; +Cc: Andreas Schwab, binutils, Stefan Reinauer
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 64bit bfd_vma vs 32bit address space in linker
2003-04-08 6:55 ` Alexandre Oliva
@ 2003-04-08 9:49 ` Alan Modra
2003-04-08 10:13 ` Alexandre Oliva
0 siblings, 1 reply; 12+ messages in thread
From: Alan Modra @ 2003-04-08 9:49 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: binutils
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 64bit bfd_vma vs 32bit address space in linker
2003-04-08 6:45 ` Alan Modra
2003-04-08 6:55 ` Alexandre Oliva
@ 2003-04-08 7:28 ` Andreas Jaeger
2003-04-08 8:53 ` Alan Modra
1 sibling, 1 reply; 12+ messages in thread
From: Andreas Jaeger @ 2003-04-08 7:28 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Andreas Schwab, binutils, Stefan Reinauer
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 64bit bfd_vma vs 32bit address space in linker
2003-04-08 7:28 ` Andreas Jaeger
@ 2003-04-08 8:53 ` Alan Modra
0 siblings, 0 replies; 12+ messages in thread
From: Alan Modra @ 2003-04-08 8:53 UTC (permalink / raw)
To: Andreas Jaeger; +Cc: Alexandre Oliva, Andreas Schwab, binutils, Stefan Reinauer
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 64bit bfd_vma vs 32bit address space in linker
2003-04-08 6:25 ` Alexandre Oliva
2003-04-08 6:45 ` Alan Modra
@ 2003-04-08 6:53 ` Thiemo Seufer
1 sibling, 0 replies; 12+ messages in thread
From: Thiemo Seufer @ 2003-04-08 6:53 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Alan Modra, Andreas Schwab, binutils, Stefan Reinauer
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2003-04-08 10:13 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-04 15:46 64bit bfd_vma vs 32bit address space in linker Andreas Schwab
2003-04-08 0:58 ` Alan Modra
2003-04-08 2:47 ` Alexandre Oliva
2003-04-08 5:17 ` Alan Modra
2003-04-08 6:25 ` Alexandre Oliva
2003-04-08 6:45 ` Alan Modra
2003-04-08 6:55 ` Alexandre Oliva
2003-04-08 9:49 ` Alan Modra
2003-04-08 10:13 ` Alexandre Oliva
2003-04-08 7:28 ` Andreas Jaeger
2003-04-08 8:53 ` Alan Modra
2003-04-08 6:53 ` Thiemo Seufer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).