why? -fPIC makes only sense on shared libraries coreutils doesmt have shared libraries
can some of the alternate architecture people comment on this?
ths discussion seems to be happening elsewhere anyway *** This bug has been marked as a duplicate of 36453 ***
*BUMP* still a problem in 5.0.91-r4 no comment from alternate architecture people after more than a month; so I asked someone with years of linux experience on lots of different achitectures. his opinnion: gentoo thinks of -fPIC as some universal cure for everything; different devs have different theories what it actually does, albeit some are wayyy off. Soemtimes its libtool not knowing how to make shared libs on some architectures, sometimes its a badly written makefile that doesnt distinguish btween shared/nonshared objects, BUT NEVER EVER should -fPIC be appended or accepted in (package-)global CFLAGS. To the outside it looks like extreme laziness on the devs side; or missing understanding; and is doing a lot of damage to gentoo's reputation already. in ELF executables (all that coreutils provides), -fPIC does nothing more than add useless cruft to every function's prolog, make one register mostly unavailable, and access all globals thru an indirect memory ref. (major performace hit in some progs) Code size incrieses by one page per 30K total size on average, and we all know what that means if cache is limited. (ever wonder why so many ppl ask why gentoo is slower compared to other distros?) I dont really care if some obskure rarely used prog does these kinds of experimental stuff, but PLEASE DO NOT DO IT IN CORE PACKAGES LIKE COREUTILS! Many Thanks.
I have not looked closely at this particular situation, but it's true that -fPIC should only be used for shared libs and should be enabled via a Makefile patch (that should also go upstream)
It's true that PIC code does use up an extra register (ebx) usually but then so do frame-pointers which are emited by default. Also a few arches depend on heavily on position independence (mips,amd64,[arm?]) and additionally don't suffer a performance impact because that's how they were designed in the first place. I can assure you the hit from PIC is not major if it's even noticable at all (nano, mili seconds we are talking here in the runtime) and on on Intel it's supposed minimal. So yes it's somewhat of an overkill unless it's needed but nothing to get bent out of shape about. Anyway best I can tell is the flag got added sometime around >coreutils-5.0-r6 && <=coreutils-5.0.91-r1(rev 1.1) However I can't tell an exact time or by who this was added so we can find out the why. Reason: the ebuild's no longer in tree which makes doing cvs rdiff kinda hard. There was nothing in the ChangeLog or cvs log that I could find. (Anybody else know how to get this info without having to restore from the Attic?)
ViewCVS is probably the easiest way, but I couldn't find it. Perhaps a fresh set of eyes can; I must be missing it somewhere.
me and my sources disaggree: 1. EBP and EBX are completely unrelated - with -fomit-frame-pointer, code size is smaller b/c there is no code to set it up (VERY minor advantage on older cpus) but I have yet to see gcc using EBP for something else if it is free - let me assure you one less register (esp EBX) when it would be otherwise available can make a world of differences on x86; and dont forget the other penelties 2. theres not a single arch in the world which requires executables to be position independent; that just doesnt make sense! (technical explenation, ne1?) And even if there was, why should us x86 users suffer? 2b no other dist is doing it 2m most common theory & biggest prob: like already said diffrent ppl have different ideas what -fPIC does, one appears to be position independent as in file system position independent 2q no1 knows who did it 2p no1 knows why 2y other distros have one single person or group who is responsible for a package who have to approve of and sign responsible for every little change and no exacly whats going on 3. Im not getting bent out of shape; its not my fault Im surrounded by superiours who had linux in there baby formular who prevent me from putting gentoo on my work boxes b/c of among lotsa other things stupid things like this b/c they think gentoo is far from production ready? 4. HTH?
Hans (reporter) is completely correct. It is completely wrong to make coreutils PIC. What is happening here is a situation where some developers ignorantly use a compiler flag to "fix a problem" without understanding the problem. The problem is not being fixed, just avoided. The root problem is never addressed. Reporter, thanks for reporting this. I have made many efforts to inform our developers about PIC, and I will continue to do so until stuff like this stops. And I will make sure that this particular issue is addressed.
This looks like it first appeared in 5.0.91, which was committed by Azarah. It also included some selinux stuff so it could have come from there. Checking with azarah to see who it came from, and why.
I am guessing that this was included in a PAX diff that azarah received, and was added to the coreutils ebuild without anyone realizing that it was just for address space randomization stuff (randomizing the base address of executables, part of a hardened initiative for Gentoo which *requires* PIC executables.) Of course, if you are not using this hardened version of Gentoo, PIC executables are not anything you'd want. I'm guessing that no one touching this ebuild realized that the append-flags -fPIC was for this hardened effort only and shouldn't have been enabled globally. solar's "defense of PIC" is not the position of Gentoo -- he has this perspective because he's working on the address-space randomization effort and is thus very interested in making sure that executables work when compiled with PIC. For x86, using PIC code for no reason is certainly quite bad.
Re comment #10 Taking advantage of PIC/PIE is desirable for some of us but never a requirement. In addition we have our own hooks that don't require us to touch ebuilds to get our desired behavior for reasons like this. So this has nothing to do with PaX. Hans, You could do yourself and us really big favor if you tested coreutils without the fPIC flag and reported the results here. (simple eh?)
a few comments: 1. (to reporter): EPB is used for other purposes w/ -fomit-frame pointer, here's a small demo (contrived example, but you can check the disassembly): void dummy(int x1, int x2, int x3, int x4, int x5, int x6) { x1 += x2; x2 += x6 - x4 - x3; x3 += x5 - x1 - x6; x4 += x3 - x6 - x5; x5 += x1 - x2 - x1; x6 += x3 + x4; printf("%d %d %d %d %d %d\n", x1,x2,x3,x4,x5,x6); } compile with -fomit-frame-pointer -O2 (or -O1). 2. the -fPIC change in question is definitely not related to PaX and the ASLR effort as we're doing it differently, via hardened-gcc, there is no need to modify individual ebuilds for this (i'm speaking of -fPIC use for our purposes, there can be of course packages where libraries are incorrectly compiled unless the ebuild enforces -fPIC).
append-flags -fPIC should certainly be removed from coreutils, noone disagrees about this. As pip already said on comment #12, this has nothing to do with the hardened team or pax because we don't use CFLAGS to enforce pic, none of us know why it is there. There are some false ideas in this bug, some architectures do in fact need PIC code but it is true that x86 users shouldn't be punished for this. You can see this if you want by looking at the output of this # grep -rE "append-flags.*-fPIC" /usr/portage as you can see *most* of those append-flags -fPIC are conditional to the ARCH, alpha, hppa and amd64 are in general the archs that require this. That output shows a few more thing that have unconditional -fPIC that shouldn't however net-www/mozilla-firebird/mozilla-firebird-0.7.ebuild: append-flags -fPIC net-dns/bind-tools/bind-tools-9.2.3.ebuild: append-flags -fPIC media-gfx/imagemagick/imagemagick-5.5.6-r1.ebuild: append-flags -fPIC These are suspect and should also be checked into as well. Others like zlib, libpcre, etc might be ok but Jon is right about the Makefile if it's actually causing an issue. Regardless, there are reasons that you'd need/want PIC code outside of hardened, and as already mentioned we don't rely on the CFLAGS at all, and therefore wouldn't have done this. However, I have an issue about the "Position of Gentoo" on PIC code. Solar's "defence of PIC" was a justification more than that. He admitted that it's an extra register and that on x86 extra overhead exists (though not on some archs) I would like clarification about Gentoo's position on PIC because I don't see it in policy anywhere, nor can I find it on the -dev or -core mailing list (within the last couple months since thats all I have in my mua)
I think the position should be: For shared libraries make sure they use -fPIC such as to allow prelinking and things. For executables, preferably not, unless there are strong reasons to do so.
well, listen, I'll be releasing coreutils-5.1.2 shortly without -fPIC for everyone to test, so please allow me the day to get that into portage.
To help clear up some of the misconceptions about PIC I've gathered up some prudent information and put together a quick little xml. At some point in the future this should be developed into policy which more or less should entail PIC on ET_DYN and XIP for ET_EXEC. Debian already has adopted such a policy for some years now. http://dev.gentoo.org/~solar/xml/pic.html
drobbins fixed this, apparently
