Re: [gentoo-embedded] hardened gcc-3.3.2 and uClibc

[Ned Ludd]

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