owl-dev - Re: %optflags for new gcc

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111106162354.GA13927@albatros>
Date: Sun, 6 Nov 2011 20:23:54 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: %optflags for new gcc

Solar,

On Sat, Nov 05, 2011 at 19:21 +0400, Solar Designer wrote:
> > http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Optimize-Options.html
> > "-fomit-frame-pointer
> > ...
> > Enabled at levels -O, -O2, -O3, -Os."
> > 
> > IOW, it it enabled by default on BOTH -O2 and -Os.
> 
> I think this is an error in the documentation.
[...]
> Notice the "when not optimizing for size" remark.  Feel free to test and
> submit a documentation patch upstream (removing ", -Os" from the list).

OK.


> And it's a curious comment that "some vendors have patched the gcc to
> make this option default" (regarding -fstack-protector).  Do you know
> any examples?  Maybe Ubuntu (just a guess)?

Yes, Ubuntu does.  I think we may patch ld and gcc to enable SSP and
-z,relro by default, but explicitly pass FORTIFY_SOURCE=2 in
spec files, which behave well with them.  

Possible problems with FORTIFY_SOURCE:

https://wiki.ubuntu.com/ToolChain/CompilerFlags#Problems

I cannot find what wrong can happen with -z,now.  I'm finding only bug
in ld's implementation of "-z now" :-)


"ld -z now" might significantly slowdown the loading of bloated apps
with tons of dynamic libraries like X apps (OpenOffice, Firefox, etc.).
Given (almost?) all official Owl programs are very small in sense of
used dynamic libraries, we probably may want to use -z,now in %optflags,
but not change binutils' defaults.  In this case all manually compiled
programs, which might be rather large and use numerous dynlibs, will not
be significantly slowed down.


BTW, one note.  From https://wiki.ubuntu.com/ToolChain/CompilerFlags:

"-D_FORTIFY_SOURCE=2

First enabled in Ubuntu 8.10. Provides compile-time best-practices
errors for certain libc functions, and provides run-time checks of
buffer lengths and memory regions. Only activated when compiled with -O2
or higher."

See the -O2 or higher restriction.  We'll need to check whether it is
-Os' case too.


> > But for bootstraping we probably should explicitly pass -fPIE to gcc in
> > gcc.spec.
> 
> Why?  What problem would we have if we don't?

Ah, my mistake - we pass %optflags to gcc anyway in gcc.spec:

    TARGET_OPT_FLAGS='%optflags'
    TARGET_OPT_LIBFLAGS='%optflags'
    #TARGET_OPT_LIBFLAGS='%{?optflags_lib:%optflags_lib}%{!?optflags_lib:%optflags}'

    # Let's compile the thing
    # STAGE1_CFLAGS is used for stage1 compiler
    # BOOT_FLAGS is used for stage2..n compiler
    # ..._FOR_TARGET is used for final compiler

    %__make bootstrap-lean \
        STAGE1_CFLAGS="-O -fomit-frame-pointer" \
        BOOT_CFLAGS="-O -fomit-frame-pointer" \
        CFLAGS_FOR_TARGET="$TARGET_OPT_FLAGS" \
        LIBCFLAGS_FOR_TARGET="$TARGET_OPT_LIBFLAGS" \
        CXXFLAGS_FOR_TARGET="${TARGET_OPT_FLAGS//-fno-rtti/}" \
        LIBCXXFLAGS_FOR_TARGET="${TARGET_OPT_LIBFLAGS//-fno-rtti/}"

So, no workaround for gcc is needed.

Thanks,

-- 
Vasiliy
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.