gcc specs

Robert Connolly robert at linuxfromscratch.org
Sat Aug 5 12:37:31 PDT 2006

On Friday 04 August 2006 06:17, Alex Merry wrote:
> On Thu, Aug 03, 2006 at 09:15:48PM -0400, Robert Connolly wrote:
> > With the hardened specs I tried building and testing Glibc with
> > CC="gcc -no-pie -fno-pic -fno-pie -norelro -nonow -no-fortify" CXX="g++
> > ..." and got about a dozen test Errors. This shouldn't be. These flags
> > should be equivalent to vanilla.
> Same. I managed to get rid of about a fifth to a quarter of the errors
> with -no-pie -fno-PIE -DFORTIFY=0, which cancelled all the flags shown
> by "gcc -v" on a dummy.c file (although running gcc -v -fno-PIE showed
> it was running gcc with -fPIE and -fno-PIE on the same command line).

I didn't know -fno-PIE was a valid flag, I should probably add it.

I have been trying one thing at a time, like -fpic in gcc specs, then building 
glibc, then replacing the specs with vanilla for make check. -fpic, -z relro, 
and -z combreloc are no problem... make check passes perfectly (just the 
posix/annexc.out ignored).

-D_FORTIFY_SOURCE=2 won't let glibc build, let alone testsuite. I added 
a !D_LIBC* condition to exclude D_FORTIFY_SOURCE, and it would build, but 
testsuite failed. Maybe -D_FORTIFY_SOURCE can be added to all the utilities 
but not the libraries, or everything but libc.so and/or ld.so, but I'm not 
sure yet.

I don't like using !D_LIBC* as conditions in the specs, its too broad. 
Using -no options where needed is more appropriate in my opinion.

-z now creates a lot of failures too. Again maybe this can be used in some 
places but not others. This option probably doesn't work on ld.so.

The fpie/pie spec creates only 1 failure, elf/tst-tls3.out. I need to retry 
with fpic/pie to see if its a linking or fpie problem

I haven't got to figuring out -fstack-protector yet. obsd adds a dummy guard 
function to ld.so, with the real guard in libc.so, so that both libc.so and 
ld.so can be built with -fstack-protector. At execution time the function 
from libc.so is used. I have to narrow down where -fstack-protector works and 
doesn't work, and see if its worth adding to rtld and if so debug it to make 
sure it works properly. I'll save this for last. The glibc-2.3.6 
fstack-protector patch I made added -fstack-protector to some places, 
while -fno-stack-protector was added to CC... I want to reverse this patch 
so -fno-stack-protector is used where needed and hopefully it doesn't even 
need to be a patch, just some sed commands.

I made some cute sed commands to add gettimeofday as a fallback in the guard 
setup function if /dev/urandom isn't available, and another for sysctl 
erandom, rather than using a patch. Substituting /dev/urandom 
with /dev/erandom is simple enough too.

> > So anyway, I don't suggest trying to use the system created by the
> > unstable book(s) right now.
> Not that I would be able to use the system I just built - the kernel
> build bales out on fs/namei.o with a gcc segfault every time.

Maybe this will get fixed with fixed gcc specs.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20060805/bff6c1e1/attachment.sig>

More information about the hlfs-dev mailing list