This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR ld/21529: Use a linker script to limit output with the test case (was: Re: PR21529, internal error in linker.c)


On Thu, Jul 13, 2017 at 9:26 AM, Maciej W. Rozycki <macro@imgtec.com> wrote:
> Complement commit d9409498813c ("Add a testcase for PR ld/21529") and
> use a linker script to prevent an inter-segment gap arranged by the
> default linker script associated with some targets such as `rx-elf':
>
> $ ld -e main -o tmpdir/dump-elf tmpdir/pr21529.o
> $ readelf -l tmpdir/dump-elf
> Elf file type is EXEC (Executable file)
> Entry point 0x10000004
> There are 2 program headers, starting at offset 52
>
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg
> Align
>   LOAD           0x001000 0x10000000 0x10000000 0x00008 0x00008 R E
> 0x1000
>   LOAD           0x001ffc 0xbffffffc 0xbffffffc 0x00004 0x00004 RW
> 0x1000
>
>  Section to Segment mapping:
>   Segment Sections...
>    00     .text
>    01     .stack
> $
>
> and converted to padding with the use of the binary BFD for output from
> producing unreasonably large files.
>
>         ld/
>         * testsuite/ld-unique/pr21529.ld: New test linker script.
>         * testsuite/ld-unique/pr21529.d: Use it.
> ---
> On Wed, 7 Jun 2017, Alan Modra wrote:
>
>> > I checked in this to add a testcase.
>>
>> Thanks, but various targets fail this testcase due to ld not
>> supporting binary output.  With the following, we're left with:
>>
>> avr-elf  +FAIL: ld-unique/pr21529
>> iq2000-elf  +FAIL: ld-unique/pr21529
>> mips64-linux  +FAIL: ld-unique/pr21529
>> mipsel-linux-gnu  +FAIL: ld-unique/pr21529
>> mipsisa32el-linux  +FAIL: ld-unique/pr21529
>> mips-linux  +FAIL: ld-unique/pr21529
>> mipstx39-elf  +FAIL: ld-unique/pr21529
>> rx-elf  +FAIL: ld-unique/pr21529
>>
>> The avr and mips fails are segfaults due to accessing ELF data
>> structures that aren't present when linking to binary.  The iq2000 and
>> rx fails are timeouts when dumping an enormous binary output.  All of
>> the fails I see are real bugs so shouldn't be hidden by xfail.  I'm
>> leaving it to the target maintainers to fix..
>
>  At least the `rx-elf' failure is not a bug of any kind, but rather
> resource exhaustion and the dump requested eventually completes.  The raw
> binary produced corresponds to what would be:
>
> Elf file type is EXEC (Executable file)
> Entry point 0x10000004
> There are 2 program headers, starting at offset 52
>
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD           0x001000 0x10000000 0x10000000 0x00008 0x00008 R E 0x1000
>   LOAD           0x001ffc 0xbffffffc 0xbffffffc 0x00004 0x00004 RW  0x1000
>
>  Section to Segment mapping:
>   Segment Sections...
>    00     .text
>    01     .stack
>
> if linked with the ELF output format.  Of course what LD produces with the
> binary output format is a sparse file:
>
> $ stat tmpdir/dump
>   File: `tmpdir/dump'
>   Size: 2952790016      Blocks: 16         IO Block: 65536  regular file
> [...]
> $
>

Why does rx-elf generate such a big file for a simple program?

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]