Readjusted linker issues etc.

robert baker robertmbaker at gmail.com
Mon Jun 8 11:40:52 PDT 2009


I had intended on going back over this stuff sooner, but I got wrapped
up in a big project for work. Now that I have finished that I have
been looking back at my binutils failures so I could get some piece of
mind.

The lack of zlib was the culprit behind some of my binutils test
failures. As I posted earlier my failures were as follows.

FAIL: run objcopy of executable
FAIL: run stripped executable
FAIL: run stripped executable with saving a symbol
FAIL: objdump -W
FAIL: readelf -wa (compressed)

The first three failures happen because objcopy fails to mark a copied
file as executable. Not sure what causes that, but simply chmoding the
file will make the tests pass. I am not too sure how worrying this
is...

The next two were failing because zlib was not available at compile
time. Even though Robert Connolly had mentioned that it was needed I
somehow missed that.

FAIL: ld-elf/seg
FAIL: vers4
FAIL: Check --gc-section/-r/-u
FAIL: ld-i386/hidden2
FAIL: NOCROSSREFS 3
FAIL: S-records
FAIL: S-records with constructors

The ld failures are a little more interesting. First ld-elf/seg fails
because of the PAX header. No concern there it should be an X-FAIL for
a pax enabled system.

Vers4 is an objdump test with --dynamic-syms. The expectation is for
no output, but the output is as follows.
00000586 g    DF .text  00000022  VERS_2.0    foo
00000000 g    DO *ABS*  00000000  VERS_2.0    VERS_2.0

Through my research I found that mips systems have this test marked
X-FAIL because of similar output. I am not entirely certain why these
two entries are present on a hardened system, but not expected on a
vanilla system. As it stands I don't have an intimate knowledge of the
elf headers, and symbol tables. (There is always more to learn.)
Anyhow I am guessing this should just be an X-FAIL for our purposes.

Check --gc-section/-r/-u fails because of a segfault on the test
compilation. This concerns me a bit. The data being compiled does
include some textrels, but with hardening flags being disabled I am
left wondering exactly why it does fail. I want to do more digging
here because it appears that it is not honoring the CFLAGS.

ld-i386/hidden2 is a regex mismatch of some sort. I need to do some
more looking to check what it expects vs what it is finding, and see
where the difference comes in...

NOCROSSREFS 3 appears to be another textrel induced failure. Not sure
why it is being compiled PIE when I have passed -nopie to make...

S-records, and S-records with constructors also appear to be textrel related.


I will be digging deeper here throughout the week, and I hope to be
able to move onto gcc by the weekend. If any of you recognize these
failures I am all ears for suggestions.

Robert Baker



More information about the hlfs-dev mailing list