Gentoo Archives: gentoo-embedded

From: Ned Ludd <solar@g.o>
To: "Peter S. Mazinger" <ps.m@×××.net>
Cc: gentoo-hardened@g.o, gentoo-embedded@g.o
Subject: Re: [gentoo-embedded] hardened gcc-3.3.2 and uClibc
Date: Wed, 19 Nov 2003 01:20:11
Message-Id: 1069204744.11184.165.camel@simple
In Reply to: [gentoo-embedded] hardened gcc-3.3.2 and uClibc by "Peter S. Mazinger"
On Tue, 2003-11-18 at 18:57, Peter S. Mazinger wrote:
> Hello! > > I have a clean uClibc environment (not gentoo based), and inspired by > hardened-gcc-3.3.2 the gcc specs file was changed to support ET_DYN > binaries, the only change I have done is replacing Scrt1.o with "crt1S.o > interp.o" (crt1S.o not yet in the uClibc tree, but in portage), due to the > fact that Scrt1.o does not exist in uClibc like in glibc-2.3.2. I do not > know what the difference is between Scrt1.o from glibc and crt1S.o coming > from the hardened-gcc-2.4.6 (the version for uClibc is PaX version, so > similar to those in hardened-gcc-2.4.6). > Could someone comment on problems regarding this change?
...
> I have seen a dependency on binutils-2.14.90.0.7, but this one has some > problems with uClibc (does not correctly support canadian cross-compiling, > binutils-2.14.90.0.6 yes). Is it really needed, or is > binutils-2.14.90.0.6-r7 enough? > > I have rebuilt about 50 packages (mainly development environment) with > these changes, but there is some strange behaviour (it is not related > to the fact that everything is -fPIC built, I had this already defined > earlier in my CFLAGS for almost all packages) > I am also interested in an Scrt1.o version for uClibc, so a changes > description between the PaX and the glibc-2.3.2 implementation would be > helpful.
<rant> Quick rundown. Sctr1.S is a redhat knock off creation of PaX's ctr1S.S (ie somebody probably got paid to rip it off and claim it was a redhat original creation) they even fscked up the naming convention. I wont go to much in detail because I would end up ranting for hours. In short Scrt1 the way it gets built by redhat will most likely end up with text relocations from what I understand so the PaX crt1S.S should be used and preferred till such time as redhat finds a way to break that for us. </rant>
> Why was the default -fomit-frame-pointer option removed? From my > experience there are only a few packages, that are incompatible with it > (mainly libraries).
You would have to ask the maintainer pappy@g.o about why this functionality was removed. However I can say from my personal testing we truly don't seem to gain any performance by trying to gain back an extra register from adding -fomit-frame-pointer when -fPIC steals away the ebx register, in fact I even get roughly exactly same number of instructions that get executed when using those flags together. Attached is a file I did this testing with. -- Ned Ludd <solar@g.o> Gentoo Linux Developer

Attachments

File name MIME type
1407.c text/x-c
signature.asc application/pgp-signature