List Archive: gentoo-embedded
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Tue, 2003-11-18 at 18:57, Peter S. Mazinger wrote:
> 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-126.96.36.199.7, but this one has some
> problems with uClibc (does not correctly support canadian cross-compiling,
> binutils-188.8.131.52.6 yes). Is it really needed, or is
> binutils-184.108.40.206.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
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.
> 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 firstname.lastname@example.org 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 <email@example.com>
Gentoo Linux Developer
1407.c (Text Data)
signature.asc (This is a digitally signed message part)