This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] PR ld/21529: Use a linker script to limit output with the test case (was: Re: PR21529, internal error in linker.c)
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Maciej W. Rozycki" <macro at imgtec dot com>
- Cc: Alan Modra <amodra at gmail dot com>, Tristan Gingold <gingold at adacore dot com>, Binutils <binutils at sourceware dot org>
- Date: Thu, 13 Jul 2017 10:48:47 -0700
- Subject: Re: [PATCH] PR ld/21529: Use a linker script to limit output with the test case (was: Re: PR21529, internal error in linker.c)
- Authentication-results: sourceware.org; auth=none
- References: <20170605082534.GV8842@bubble.grove.modra.org> <CAMe9rOq9sAeH9h-mzR3Hphmfjr-osYYs90Ds5qjnCQY86BpC6Q@mail.gmail.com> <20170607083948.GY8842@bubble.grove.modra.org> <alpine.DEB.2.00.1707130236510.29665@tp.orcam.me.uk>
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.