using a completely fresh and stable install on amd64 (except for dejagnu, which isn't marked amd64 at all for some reason), binutils 2.14.90.0.8-r1 fails to make check: === ld Summary === # of expected passes 127 # of unexpected failures 6 # of expected failures 36 specific failures: Running /var/tmp/portage/binutils-2.14.90.0.8-r1/work/binutils-2.14.90.0.8/ld/testsuite/ld-selective/selective.exp ... FAIL: selective1 FAIL: selective2 FAIL: selective4 FAIL: selective5 Running /var/tmp/portage/binutils-2.14.90.0.8-r1/work/binutils-2.14.90.0.8/ld/testsuite/ld-x86-64/x86-64.exp ... FAIL: TLS -fpic -shared transitions FAIL: TLS -fpic and -fno-pic exec transitions
out of curiousity i just ran the same tests on 2.15.90.0.1.1-r1: === ld Summary === # of expected passes 131 # of unexpected failures 2 # of expected failures 36 # of unresolved testcases 6 Running /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-selective/selective.exp ... ERROR: /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-selective/1.c: compilation failed ERROR: /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-selective/2.c: compilation failed ERROR: /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-selective/2.c: compilation failed ERROR: /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-selective/3.cc: compilation failed ERROR: /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-selective/4.cc: compilation failed ERROR: /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-selective/5.cc: compilation failed Running /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-x86-64/x86-64.exp ... FAIL: TLS -fpic -shared transitions FAIL: TLS -fpic and -fno-pic exec transitions ....right.
...and for completeness, similar results with binutils 2.15.90.0.3-r1: === ld Summary === # of expected passes 137 # of unexpected failures 6 # of expected failures 37 Running /var/tmp/portage/binutils-2.15.90.0.3-r1/work/binutils-2.15.90.0.3/ld/testsuite/ld-selective/selective.exp ... FAIL: selective1 FAIL: selective2 FAIL: selective4 FAIL: selective5 Running /var/tmp/portage/binutils-2.15.90.0.3-r1/work/binutils-2.15.90.0.3/ld/testsuite/ld-x86-64/x86-64.exp ... FAIL: TLS -fpic -shared transitions FAIL: TLS -fpic and -fno-pic exec transitions
also, this isnt a hardened gcc so there isnt any spec-file fun going on: ayanami gcc # gcc --version gcc (GCC) 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7)
commenting out the epatch line for 2.14.90.0.8-r1 results in 2 fewer unexpected failures: === ld Summary === # of expected passes 129 # of unexpected failures 4 # of expected failures 36 Running /var/tmp/portage/binutils-2.14.90.0.8-r1/work/binutils-2.14.90.0.8/ld/testsuite/ld-selective/selective.exp ... FAIL: selective1 FAIL: selective2 FAIL: selective4 FAIL: selective5 i'll poke at this more after some sleep and a hefty dose of caffeine.
one final note: i've filed this bug mostly to make sure i dont forget that it exists. i tend to do that. also... i'm guessing the pic stuff can be ignored, but i'm curious as to why selective linking is borked... 0.o
siti gets 37 failures on x86, but refuses to get a bugzilla account. 0.o also, ppc64 seems to be getting a number of failures in ld as well: === ld Summary === # of expected passes 90 # of unexpected failures 29 # of expected failures 1 Running /var/tmp/portage/binutils-2.14.90.0.8-r1/work/binutils-2.14.90.0.8/ld/testsuite/ld-elfvsb/elfvsb.exp ... FAIL: visibility (hidden_normal) (non PIC) FAIL: visibility (hidden_normal) (non PIC, load offset) FAIL: visibility (hidden_normal) (PIC main, non PIC so) FAIL: visibility (hidden_weak) (non PIC) FAIL: visibility (hidden_weak) (non PIC, load offset) FAIL: visibility (hidden_weak) (PIC main, non PIC so) FAIL: visibility (protected) (non PIC) FAIL: visibility (protected) (non PIC, load offset) FAIL: visibility (protected) (PIC main, non PIC so) FAIL: visibility (protected_undef_def) (non PIC) FAIL: visibility (protected_undef_def) (non PIC, load offset) FAIL: visibility (protected_undef_def) (PIC main, non PIC so) FAIL: visibility (protected_weak) (non PIC) FAIL: visibility (protected_weak) (non PIC, load offset) FAIL: visibility (protected_weak) (PIC main, non PIC so) FAIL: visibility (normal) (non PIC) FAIL: visibility (normal) (non PIC, load offset) FAIL: visibility (normal) (PIC main, non PIC so) Running /var/tmp/portage/binutils-2.14.90.0.8-r1/work/binutils-2.14.90.0.8/ld/testsuite/ld-powerpc/powerpc.exp ... FAIL: TLS32 static exec FAIL: TLS32 dynamic exec FAIL: TLS32 shared FAIL: TLS static exec FAIL: TLS dynamic exec FAIL: TLS shared FAIL: TLSTOC static exec FAIL: TLSTOC dynamic exec FAIL: TLSTOC shared Running /var/tmp/portage/binutils-2.14.90.0.8-r1/work/binutils-2.14.90.0.8/ld/testsuite/ld-selective/selective.exp ... FAIL: selective4 FAIL: selective5 Dual-G5 binutils-2.14.90.0.8 # gcc --version gcc (GCC) 3.3.3 (Gentoo Linux 3.3.3_pre20040215) binutils 2.15.90.0.1.1-r1 on ppc64: === ld Summary === # of expected passes 97 # of unexpected failures 27 # of expected failures 2 Running /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-elfvsb/elfvsb.exp ... FAIL: visibility (hidden_normal) (non PIC) FAIL: visibility (hidden_normal) (non PIC, load offset) FAIL: visibility (hidden_normal) (PIC main, non PIC so) FAIL: visibility (hidden_weak) (non PIC) FAIL: visibility (hidden_weak) (non PIC, load offset) FAIL: visibility (hidden_weak) (PIC main, non PIC so) FAIL: visibility (protected) (non PIC) FAIL: visibility (protected) (non PIC, load offset) FAIL: visibility (protected) (PIC main, non PIC so) FAIL: visibility (protected_undef_def) (non PIC) FAIL: visibility (protected_undef_def) (non PIC, load offset) FAIL: visibility (protected_undef_def) (PIC main, non PIC so) FAIL: visibility (protected_weak) (non PIC) FAIL: visibility (protected_weak) (non PIC, load offset) FAIL: visibility (protected_weak) (PIC main, non PIC so) FAIL: visibility (normal) (non PIC) FAIL: visibility (normal) (non PIC, load offset) FAIL: visibility (normal) (PIC main, non PIC so) Running /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-powerpc/powerpc.exp ... FAIL: TLS32 static exec FAIL: TLS32 dynamic exec FAIL: TLS32 shared FAIL: TLS static exec FAIL: TLS dynamic exec FAIL: TLS shared FAIL: TLSTOC static exec FAIL: TLSTOC dynamic exec FAIL: TLSTOC shared and just for the sake of completeness: === ld Summary === # of expected passes 97 # of unexpected failures 29 # of expected failures 2 Running /var/tmp/portage/binutils-2.15.90.0.3-r1/work/binutils-2.15.90.0.3/ld/testsuite/ld-elfvsb/elfvsb.exp ... FAIL: visibility (hidden_normal) (non PIC) FAIL: visibility (hidden_normal) (non PIC, load offset) FAIL: visibility (hidden_normal) (PIC main, non PIC so) FAIL: visibility (hidden_weak) (non PIC) FAIL: visibility (hidden_weak) (non PIC, load offset) FAIL: visibility (hidden_weak) (PIC main, non PIC so) FAIL: visibility (protected) (non PIC) FAIL: visibility (protected) (non PIC, load offset) FAIL: visibility (protected) (PIC main, non PIC so) FAIL: visibility (protected_undef_def) (non PIC) FAIL: visibility (protected_undef_def) (non PIC, load offset) FAIL: visibility (protected_undef_def) (PIC main, non PIC so) FAIL: visibility (protected_weak) (non PIC) FAIL: visibility (protected_weak) (non PIC, load offset) FAIL: visibility (protected_weak) (PIC main, non PIC so) FAIL: visibility (normal) (non PIC) FAIL: visibility (normal) (non PIC, load offset) FAIL: visibility (normal) (PIC main, non PIC so) Running /var/tmp/portage/binutils-2.15.90.0.3-r1/work/binutils-2.15.90.0.3/ld/testsuite/ld-powerpc/powerpc.exp ... FAIL: TLS32 static exec FAIL: TLS32 dynamic exec FAIL: TLS32 shared FAIL: TLS static exec FAIL: TLS dynamic exec FAIL: TLS shared FAIL: TLSTOC static exec FAIL: TLSTOC dynamic exec FAIL: TLSTOC shared Running /var/tmp/portage/binutils-2.15.90.0.3-r1/work/binutils-2.15.90.0.3/ld/testsuite/ld-selective/selective.exp ... FAIL: selective4 FAIL: selective5
with gcc 3.4.0-r1 on ppc64 with binutils 2.15.90.0.1.1-r1 === ld Summary === # of expected passes 88 # of unexpected failures 34 # of expected failures 2 # of unresolved testcases 2 Running /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-elfvsb/elfvsb.exp ... FAIL: visibility (hidden_normal) (non PIC) FAIL: visibility (hidden_normal) (non PIC, load offset) FAIL: visibility (hidden_normal) (PIC main, non PIC so) FAIL: visibility (hidden_undef_def) (non PIC) FAIL: visibility (hidden_undef_def) (non PIC, load offset) FAIL: visibility (hidden_undef_def) FAIL: visibility (hidden_undef_def) (PIC main, non PIC so) FAIL: visibility (hidden_undef_def) (PIC main) FAIL: visibility (hidden_weak) (non PIC) FAIL: visibility (hidden_weak) (non PIC, load offset) FAIL: visibility (hidden_weak) (PIC main, non PIC so) FAIL: visibility (protected) (non PIC) FAIL: visibility (protected) (non PIC, load offset) FAIL: visibility (protected) (PIC main, non PIC so) FAIL: visibility (protected_undef_def) (non PIC) FAIL: visibility (protected_undef_def) (non PIC, load offset) FAIL: visibility (protected_undef_def) (PIC main, non PIC so) FAIL: visibility (protected_weak) (non PIC) FAIL: visibility (protected_weak) (non PIC, load offset) FAIL: visibility (protected_weak) (PIC main, non PIC so) FAIL: visibility (normal) (non PIC) FAIL: visibility (normal) (non PIC, load offset) FAIL: visibility (normal) (PIC main, non PIC so) Running /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-powerpc/powerpc.exp ... FAIL: TLS32 static exec FAIL: TLS32 dynamic exec FAIL: TLS32 shared FAIL: TLS static exec FAIL: TLS dynamic exec FAIL: TLS shared FAIL: TLSTOC static exec FAIL: TLSTOC dynamic exec FAIL: TLSTOC shared Running /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-selective/selective.exp ... FAIL: selective4 FAIL: selective5 so, the same stuff only with more PIC related failures. (possibly due to specfile changes) gcc 3.4.0 fixes sdiff on ppc64, which no longer segfaults at least... i really need to update the pie spec stuff in 3.4 anyways.
ppc64 + gcc 3.4.0-r1 + binutils 2.15.0.1.1 with no patches applied whatsoever: === ld Summary === # of expected passes 97 # of unexpected failures 25 # of expected failures 2 # of unresolved testcases 2 ERROR: /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-cdtest/cdtest-foo.cc: compilation failed all other failures in elfvsb.exp and selective.exp like before... i'll do more testing after updating gcc 3.4.0 to be more in sync with the current pie patches and such. removing amd64 from CC, as i somehow got distracted from working on my own arch and am instead working on just ppc64 0.o
another side-note.. from inside amd64 suse: ldd -r /lib/libreadline.so.4.3 linux-gate.so.1 => (0xffffe000) libncurses.so.5 => /lib/libncurses.so.5 (0x555aa000) libc.so.6 => /lib/tls/libc.so.6 (0x555ef000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x56555000) or for 64bit in amd64 suse: ldd -r /lib64/libreadline.so.4.3 libncurses.so.5 => /lib64/libncurses.so.5 (0x0000002a956b8000) libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a9581a000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000) from inside amd64 gentoo: ldd -r /lib/libreadline.so.4.3 libc.so.6 => /lib/libc.so.6 (0x0000002a956aa000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000) undefined symbol: BC (/lib/libreadline.so.4.3) undefined symbol: PC (/lib/libreadline.so.4.3) undefined symbol: UP (/lib/libreadline.so.4.3) undefined symbol: tgetnum (/lib/libreadline.so.4.3) undefined symbol: tgoto (/lib/libreadline.so.4.3) undefined symbol: tgetflag (/lib/libreadline.so.4.3) undefined symbol: tputs (/lib/libreadline.so.4.3) undefined symbol: tgetent (/lib/libreadline.so.4.3) undefined symbol: tgetstr (/lib/libreadline.so.4.3) and on ppc64 gentoo: Dual-G5 root # ldd -r /lib/libreadline.so.4.3 libc.so.6 => /lib/libc.so.6 (0x0000008000063000) /lib64/ld64.so.1 => /lib64/ld64.so.1 (0x0000000008000000) undefined symbol: PC (/lib/libreadline.so.4.3) undefined symbol: BC (/lib/libreadline.so.4.3) undefined symbol: UP (/lib/libreadline.so.4.3) undefined symbol: tgetnum (/lib/libreadline.so.4.3) undefined symbol: tgoto (/lib/libreadline.so.4.3) undefined symbol: tgetflag (/lib/libreadline.so.4.3) undefined symbol: tputs (/lib/libreadline.so.4.3) undefined symbol: tgetent (/lib/libreadline.so.4.3) undefined symbol: tgetstr (/lib/libreadline.so.4.3) yeah. i'd say our ld is pretty fubar.
oh yeah, and for completeness, here's x86: ayanami / # ldd -r /lib/libreadline.so.4.3 linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/libc.so.6 (0x55584000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x56555000) undefined symbol: BC (/lib/libreadline.so.4.3) undefined symbol: PC (/lib/libreadline.so.4.3) undefined symbol: UP (/lib/libreadline.so.4.3) undefined symbol: tgetnum (/lib/libreadline.so.4.3) undefined symbol: tgoto (/lib/libreadline.so.4.3) undefined symbol: tgetflag (/lib/libreadline.so.4.3) undefined symbol: tputs (/lib/libreadline.so.4.3) undefined symbol: tgetent (/lib/libreadline.so.4.3) undefined symbol: tgetstr (/lib/libreadline.so.4.3)
A quick check on sparc64 and mips reveals libreadline is broken there too, or atleast missing those symbols. A quick google search indicates this is a longstanding readline/linux problem, and some distributions still exhibit it. It seems at a preliminary glance, anything that needs to link in -lreadline will also need to link in -lncurses as well, in order for the undefined symbols to get resolved. I'm poking around to see if there is a more permanent solution for readline itself.
Not just linux, I also found a few references to solaris systems having the same issue. Also, the undefined symbols are also provided by -ltermcap and -ltinfo, which makes three different libs that provide the symbols. Fun part it seems to determining what lib a package may want if it needs readline's support in (I assume -lncurses is default in alot of cases). http://op.gfz-potsdam.de/GRASS-List/Archive/msg10175.html
alrighty. did a make check on suse amd64 and got: === ld Summary === # of expected passes 134 # of expected failures 41 then i moved the source tree without any modifications, did a make clean && make && make check: === ld Summary === # of expected passes 127 # of expected failures 36 # of unresolved testcases 6 # of untested testcases 6 things that make you go hmmmmm...
ok, concentrating on amd64 for the moment. the problem seems to be one part dejagnu, one part binutils, and one part gcc... suse 9.1 binutils 2.15.90.0.1.1, compiled on gentoo amd64 using portage: === ld Summary === # of expected passes 134 # of expected failures 41 ayanami binutils-2.15.90.0.1.1 # gcc --version gcc (GCC) 3.3.3-hammer with dejagnu-1.4.4-r1, which includes a patch that fixes a pic/PIC regex and ignores invalid linker warnings when searching 64bit libraries in /lib. suse binutils was failing when compiled in gentoo, but not suse, even though it was the exact same tree. more poking into gcc will be needed to figure out why our gcc is screwing things up.
the TLS failures on amd64 are due to 90_all_binutils-2.14.90.0.8-pt-pax-flags.patch.bz2 in binutils. i'm assuming the symbol visibility problem on ppc64 is related, but i have yet to actually test that. the selective linking problems are 100% gcc borkiness.
Show me how it's related please.
PT_LOOS: 0x60000000 PT_HIOS: 0x6ffffffa PT_PAX_FLAGS: 0x65041580 As we can clearly see this falls within legal boundaries. What probably going on here is that may be because said tests haven't been updated.
with the pt pax patch applied to binutils: lv@ayanami lv $ gftp Segmentation fault with the patch removed and glibc recompiled: lv@ayanami lv $ gftp Killed (gdb) run Starting program: /usr/bin/gftp-gtk warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Warning: Cannot insert breakpoint -2. Error accessing memory address 0x12490: Input/output error. 0.o i am also now getting visibility problems similar to ppc64 when using gcc 3.4.0-r1 and USE=hardened. solar: with the pax patch applied, the tests fail. with the pax patch not applied, they pass. you're more familiar with the patch, why dont you tell me why it's related? as for the ppc64 symbol visibility crap... yeah, i have no idea what i was thinking. but removing the patch does fix all TLS failures on ppc64.
recompiling everything with gcc 3.3.3-hammer (without any gentoo patches) and binutils 2.15.90.0.1.1-r1 without the pax patch (almost) fixes gftp. i'm assuming it will also help nautilus, which is dying with the exact same error: 0x(number) in pthread_getconcurrency () from /lib/libpthread.so.0. now gftp needs to actually attempt to download something in order to crash, unlike before when all you needed was to connect to an ftp server. (gdb) run Starting program: /usr/bin/gftp-gtk warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIG32, Real-time event 32. 0x0000002a967bf14e in pthread_create () from /lib/libpthread.so.0 (gdb) backtrace #0 0x0000002a967bf14e in pthread_create () from /lib/libpthread.so.0 Segmentation fault hmm. i'm guessing that there are other issues here that prevent this from being an accurate test. *sigh* this is getting to be frustrating,
please try the gcc-3.3.3_pre20040408-r1 snapshot in portage
that ebuild has some issues... besides spitting out epatch errors, it installs libgcc_s in the wrong place on amd64 and probably ppc64 as well. hmm... i see that versioned directories are disabled on ppc64. that is an ugly way to hack around the problem... all you need to do is copy the contents of lib32 and lib64 to the versioned directory before merging to ${ROOT} (or just lib64 if that is all that exists) pcburn / # env-update /usr/bin/python: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory anyways. off to "cp /usr/lib/gcc-lib/x86_64-pc-linux-gnu/lib64/libgcc_s.so* /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/" and continue testing...
using that gcc ebuild and binutils 2.15.90.0.1.1-r1 without the pt pax patch on amd64 results in make check passing flawlessly. i cant log into the ppc64 box and poke around there because i'm not anywhere near my ssh key, but i definately will as soon as i am.
and just for completeness, with the only difference being the pax patch: === ld Summary === # of expected passes 132 # of unexpected failures 2 # of expected failures 41 Running /var/tmp/portage/binutils-2.15.90.0.1.1-r1/work/binutils-2.15.90.0.1.1/ld/testsuite/ld-x86-64/x86-64.exp ... FAIL: TLS -fpic -shared transitions FAIL: TLS -fpic and -fno-pic exec transitions so on amd64, our gcc borks selective linking. and the pax patch borks thread local storage.
Think about it for a second. Your trying to set a breakpoint inside of a shared object. This wont work, does not work, and can't work. What your calling breakage is something how it was designed to behave. (fact) Interpolation is not possible within shared objects. I've also told you before more than one time that piessp was still in active development in the 3.3.3 branch. You are using an out dated patch in addition to something that none of us has tested. Now... Tell me why. (don't answer me with another question) I want to know why in detail you think(know) that an extra program header would cause thread local storage problems. I like you and I'm going to be very honest with you here. Your discrediting our work and spreading FUD and it's borderline pissing me off. If you are willing to make such assertions as to saying the PaX binutils patch breaks local thread storage then you better be able to back up those words. So... Go read the code then come back and tell us exactly how you think(know) it breaks. Re: comment #22 Did you even read comment #17 ?
except for ppc64, i've been using gcc-3.3.3.ebuild inside a clean stage3 chroot. did you even read comment #3 where i specifically state that anything there (at least for the amd64 testing) isn't at ALL due to the new piessp patches because i was using a version of GCC that doesn't even USE them?! jesus christ dude, i am not spreading FUD. i'm trying to figure out make check failures on all archs so as to get rid of them and get a nice stable, working toolchain on all archs. I just tracked down the /what/. I dont KNOW why yet... that's the whole point here: trying to figure that one out. it doesnt make sense to me either why this small patch does anything... the PT_TLS case in elf.c checked before PT_PAX_FLAGS is even evaluated. the section lower down where 'segment->p_type != PT_PAX_FLAGS' is evaluated before '(segment->p_type != PT_TLS || (section->flags & SEC_THREAD_LOCAL))' shouldn't matter either. why not stop getting defensive and actually help me here? BAH. and DOUBLE BAH. you take yourself (and me, it seems) way too seriously.
Sorry I do/did not mean to come off like an ass to you but I take great pride in the work and I often find myself having to stick up for security. Anyway if something is truly misbehaving then I would want to know the 'when/where/why'. Simply saying without X Y works felt similar to finger pointing without justification. Anyway I'm just trying to prevent negative seed planting which could lead later to a grounds for removal of the patch ;/ Which would break things for users/servers that only support PT_PAX_FLAGS now that EI_PAX flags have been deprecated. I will unpack binutils and dig around and see what I can test & confirm or debunk. From your side can you make sure that you do not have -fPIC/-fPIE/-fstack-protector/-fstack-protector-all/-z pie/-z relro/-z now/ enabled either automaticly (via gcc specs) or from make.conf
yeah dude, i think pax is the coolest shit ever. especially on amd64, where i would even suggest making it a default (kernel patch anyways) at some point due to the native NX support. :) but these make check problems are kinda freaky 0.o as for make.conf: CFLAGS="-O2 -fno-strict-aliasing" CHOST="x86_64-pc-linux-gnu" CXXFLAGS="${CFLAGS}" MAKEOPTS="-j4" ACCEPT_KEYWORDS="~amd64" CLEAN_DELAY="0" pcburn / # gcc --version gcc (GCC) 3.3.3 (Gentoo Linux 3.3.3_pre20040408-r1) PIE/pie/relro/stack-protector are nowhere to be found in the specs file
Travis can you please post some examples of the command line your using to get these results so I may preform the same tests.
for the amd64/TLS 'breakage': if you look at the tests (ld/testsuite/ld-x86-64x86-64.exp) you'll see that it uses the run_ld_link_tests function which is in ld/testsuitelib/ld-lib.exp and is nicely commented. basically, simple readelf/objdump/etc output is compared against a predefined result. now if you look at the readelf outputs (.rd files) you'll notice that it (of course) doesn't contain the PT_PAX_FLAGS program header so any comparison against that will fail. simply update the expected test results and it should be ok (i don't have amd64 so i can't do it myself, not to mention the other archs). alternatively we can disable automatic generation of PT_PAX_FLAGS but then we'll be in more pain in actual use: we'd have to be able to pass down/enforce some ld flag to always produce it. your call.
solar: you mean make check? emerge dejagnu for runtest and then run make check after make. PaX team: ahhh.... that would explain why i couldnt find anything actually wrong after looking at the code. i assumed that the tests wouldnt be so simple and easily broken... i definately think we need to update the test cases along with the pax patch to prevent people like me from getting confused as fsck in the future. ;) thanks for the input, i appreciate it... really, i would have torn my hair out looking at the patch before even looking at the testsuite. i have access to x86, amd64, ppc, ppc64, and i can even ressurrect a crappy old r4k mips box if you need someone to send you output after the patch. i'm going to assume that the selective linking tests are equally retarded? as well as the symbol visibility tests? actually, there might be something to those, as the selective linking tests sometimes fail to compile at all. hmm... i'll look a those later, probably after mother's day is over. thanks again dude, you seriously have no idea how much random frustration you probably just saved me from. *shakes head*
Well here is the thing with updating the testsuite. If we update all the tests then it should be merged upstream. If it's not merged then it's just makes keeping the pax binutils more complicated and a maintenance nightmare. It's been our experience that upstream (redhat) does not care about PaX for whatever reasons. Now if your willing to fight the upstream battle then (maybe?) we can update the testsuite.
no, i'm not going to fight with upstream if they already dont seem pleased with the idea. another very interesting side-note: 24-53-15-39 binutils # ldd /lib/libreadline.so libc.so.6 => /lib/libc.so.6 (0x0000002a956a8000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000) installed versions of apps: sys-devel/gcc-3.3.3-r4 sys-devel/binutils-2.15.90.0.1.1-r2 i'll be committing the binutils ebuild shortly, it isnt very different from -r1. it contains a backport of relro and the tbss patch from 2.15.90.0.3-r2. i should port the new piessp patches to gcc 3.4, and see if i still have no undefined symbol messages... if so, it might be a good idea to try this combination on ppc64 to see if it does anything for the symbol visibility "make check" failures.
holy crap, i forgot the -r. nevermind. ignore me. i'm going to sleep now before i accidentally break something. O_O
marking my own bug as invalid for now
