New x86 linker testsuite failure

[Alan Hayward]

> On 28 Jun 2018, at 05:03, Alan Modra <amodra@gmail.com> wrote:
> 
> On Wed, Jun 27, 2018 at 01:35:53PM +0000, Alan Hayward wrote:
>> Is the following patch ok?
> 
> No.  With changes like this you really do need to run the testsuite
> over all supported ELF targets.
> 

Ok.

>> This both restores my previous code and fixes
>> up the macros. Ensured the ld alloc test now passes and the gdb works with
>> armlinker binaries.
> 
> The patch results in some testsuite failures.
> 
> alpha-linux  +FAIL: ld-elf/mbind1b
> alpha-linux  +FAIL: ld-elf/mbind1c
> i686-nacl  +FAIL: strip -shared (maxpage1)
> i686-nacl  +FAIL: objcopy -shared (maxpage1)
> i686-nacl  +FAIL: objcopy -shared -z noseparate-code (tdata2)
> i686-nacl  +FAIL: objcopy -shared -z separate-code (tdata2)
> i686-nacl  +FAIL: objcopy -shared -z noseparate-code (tbss2)
> i686-nacl  +FAIL: objcopy -shared -z separate-code (tbss2)
> rx-elf  +XPASS: ld-scripts/rgn-at9
> x86_64-nacl  +FAIL: strip -shared (maxpage1)
> x86_64-nacl  +FAIL: objcopy -shared (maxpage1)
> x86_64-nacl  +FAIL: objcopy -shared -z noseparate-code (tdata2)
> x86_64-nacl  +FAIL: objcopy -shared -z separate-code (tdata2)
> x86_64-nacl  +FAIL: objcopy -shared -z noseparate-code (tbss2)
> x86_64-nacl  +FAIL: objcopy -shared -z separate-code (tbss2)
> 

Is there anything you can point me at for easily compiling the nacl versions?
And/or anywhere that lists all the targets I should be testing?
I can’t find anything obvious anywhere.
(Or ideally a test farm I could throw a patch at?)

I suspect that these tests also failed with my original patch (the one
that was committed).

I tried a cross alpha-linux cross build, but I get failure on alpha-linux
mbind1b and mbind1c with and without my patches
( "Fatal error: bad .section directive: want a,s,w,x,M,S,G,T in string" )
Possible I’m using the wrong versions of tools or some other error.


> They appear to be due to changed handling of zero length sections.
> For instance, readelf -lS on first x86_64-nacl testcase shows:
> 

Many thanks for the breakdown on the failure.

> Notice that the zero length .eh_frame is reported by readelf as
> belonging to the last PT_LOAD segment, which isn't correct for its
> VMA.  (Prior to your patch readelf omitted .eh_frame from the section
> to segment mapping.)  The proper location for .eh_frame is at the end
> of the second PT_LOAD segment, but because it is now wrongly mapped to
> the last PT_LOAD segment strip produces:

A zero sized section does sound very odd.

At this point I’m not convinced that adding a “if size is 0 then use addresses
instead of offsets” is the solution - feels like I’m weaving around corner
cases. I will have to think about this some more.

If I did get a valid solution soon is there a chance it could get into 2.31
or has that been missed now?


Thanks!

Alan.