bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Option -n does not work with ld in binutils-2.12


From: Tobias Ringstrom
Subject: Re: Option -n does not work with ld in binutils-2.12
Date: Wed, 10 Apr 2002 16:32:50 +0200 (CEST)

On 10 Apr 2002, Nick Clifton wrote:

> Hi Tobias,
> 
> > I think there is a bug somewhere in the option parsing of ld,
> > because -n is not the same as --nmagic (which works).  My guess is
> > that ld interprets -n as the beginning of '-nostdlib' or something
> > similar.
> 
> Hmm, that should not be happening.  Can you provide an example please? 

It is easy to see because of the (presumed) bug below.  Here you can see 
that -n does not do the same as --nmagic:

$ arm-elf-ld -V
GNU ld version 2.12
  Supported emulations:
   armelf
$ arm-elf-ld -Ttmp2.lds crt.o -o tmp.elf
arm-elf-ld: tmp.elf: Not enough room for program headers, try linking with -N
arm-elf-ld: final link failed: Bad value
$ arm-elf-ld -Ttmp2.lds -n crt.o -o tmp.elf
arm-elf-ld: tmp.elf: Not enough room for program headers, try linking with -N
arm-elf-ld: final link failed: Bad value
$ arm-elf-ld -Ttmp2.lds --nmagic crt.o -o tmp.elf
$

Adding a little printf in the code will probably show that the option 
handling for -n/--nmagic is not reached.

> > I also think there is something strange going on with the automatic
> > ELF PHDRS generation, at least for ARM.  I'll look closer at that
> > soon, but I wondering if this is a known trouble area.
> 
> It can be a problem if you are using a custom linker script, or you
> are run strip on your linked executable.  But the code should be doing
> the right thing, so if something is going wrong, then it is a bug.

Yes, it is a custom link script, but that is supported, isn't it?  I've
tried to make it really really short.  First, here is my source crt.s:

        .text
        .global         __reset
__reset:
        nop
        nop
        nop
        nop
        nop
        nop
        nop
        nop

Here is my link script tmp2.lds:

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(__reset)
SECTIONS
{
        .text 0 : AT ( 0x2000 ) { *(.text); }
}

Then I run the following:
$ arm-elf-as crt.s -o crt.o
$ arm-elf-ld -Ttmp2.lds crt.o
arm-elf-ld: a.out: Not enough room for program headers, try linking with -N
arm-elf-ld: final link failed: Bad value

If I change the vaddr of the .text section to say 0x1000, it works, but 
then the program headers look strange:

$ arm-elf-objdump -hp a.out

a.out:     file format elf32-littlearm

Program Header:
    LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**15
         filesz 0x00001020 memsz 0x00001020 flags rwx
    LOAD off    0x00009000 vaddr 0x00001000 paddr 0x00002000 align 2**15
         filesz 0x00000020 memsz 0x00000020 flags r-x
private flags = 0: [APCS-32] [FPA float format]

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000020  00001000  00002000  00009000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .glue_7       00000000  00001020  00001020  00001020  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .glue_7t      00000000  00001020  00001020  00001020  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .data         00000000  00001020  00001020  00001020  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  4 .bss          00000000  00001020  00001020  00001020  2**0
                  ALLOC

(It does not help to add "support" for .data and .bss)

Do you agree that I should not need --nmagic in this case, or is there 
somthing wrong with my link script?

/Tobias




reply via email to

[Prev in Thread] Current Thread [Next in Thread]