[gentoo-amd64] Re: gcc 4.1 + CFLAGS

[Duncan]

Kirby Walborn <kirby@×××××××××××××.com> posted
44895C73.7090207@×××××××××××××.com, excerpted below, on  Fri, 09 Jun 2006
05:33:07 -0600:

> I see you have some ldflags listed.  Where can a person find information
> on these.  I've tried to google around about them and haven't had much
> luck trying to figure it out.
>
> BTW my cflags are:
>
> CFLAGS="-march=k8 -Os -pipe -fomit-frame-pointer -frename-registers -
> -funit-at-a-time -fweb -freorder-blocks -freorder-blocks-and-partition -
> -ftree-pre -fmerge-all-constants"
> CXXFLAGS="-march=k8 -Os -pipe -fomit-frame-pointer -frename-registers -
> -funit-at-a-time -fweb -freorder-blocks -ftree-pre -fmerge-all-constants"
>
> Duncan mentioned these a while ago and I used them with no problems. But I
> was curious about ldflags if anybody has pointers.

I noticed they looked familiar.  =8^)

The only ldflags I use are:

LDFLAGS="-Wl,-z,now"

If you pay attention to your emerge output, you will have likely seen
warnings about various SETUID/SETGID applications, where the ebuild hasn't
set this flag.  It's a minor security issue for these apps, as one attack
vector would be preloading an exploitable library into an otherwise safe
SETUID/SETGID app run as root, then exploiting the hole in the library to
run your choice of malware -- as root!  Obviously, this isn't a huge issue
on a system where all the human users have root access anyway, but those
running hardened systems (note that Gentoo-hardened has a slightly
different solution in their hardened-patched gcc that does the same thing,
a slightly different way) will be interested, and the flag is a good idea
for SETGID/SETUID executables even on single-human-user systems, as it
shrinks the potential exposure to crackers and malware, helping keep Linux
from becoming another MSWormOS.

What the flag actually does is cause the resolution of all called
routines up front at application load time, thus triggering the
immediate load of all required dynamic-load libraries they are in, rather
than leaving some of them to "lazy load" later, as they are actually
needed.

Other than the security aspect for SETGID/UID, this has the effect on
all apps of increasing the initial load time of apps somewhat, as the
various libraries are all loaded and linked in, resolving the various
stubs into the full routines. Memory use can also be slightly higher,
where libraries are loaded that otherwise wouldn't be, because the part of
the application that uses them never happens to be run in that particular
session. However, over time, they'd likely be loaded by some app or
another anyway, so the practical effect isn't much more than increasing
the initial load time slightly, at the same time increasing responsiveness
later, when the app would otherwise have to load that library off of disk
or at least load it into its memory space (if it's already in memory
generally) and fully resolve the call triggering the load.

Completely resolving at load time the calls that would otherwise be
resolved as needed also has a debugging/troubleshooting effect.  Any
failed resolutions happen right away, at application load, rather than
later.  This is one of the reasons I like it, as if it's possible, I much
prefer the failure up front to having it occur after I've spent some time
with the app and possibly have unsaved work.

So basically... it's not so much an optimization as a configuring my
system to work the way I prefer it to work.  I prefer to front-end load
the library loading and routine resolution process, and know right away if
there is a problem.  I prefer waiting a half-second or so longer at
application load time to a pause later.  On tight memory systems, the
additional memory use might be significant, but it certainly wasn't when I
had a gig of memory (I've since upgraded to eight).  Note that if the
memory is needed for something else and the library hasn't been used, that
memory will be flushed to swap along with other non-actively used memory,
so it's not as if it should be a big problem for most even with a half a
gig of memory, tho below that, I'd not recommend it.

Problems?  None I've found with one SIGNIFICANT exception, but I deal with
it. The exception is modular-X, specifically xorg-server and certain
xf86-video-* drivers (among them -ati, which I use, but also a via driver
IIRC and there may be others).  The problem is that for years, as xfree86
and xorg before it went modular, these things used a build and module load
system that encouraged seriously interlocking dependencies, and these
haven't been fully ironed out as yet.  Various modules depend on functions
from other modules, which in turn depend on functions in the first
modules, so it's impossible to create a load order that resolves all
function dependencies as they are loaded.  Resolution of certain
dependencies MUST be put off until later, to load the first module, so the
second one, that requires the first, can load, thereby resolving the stubs
in the first one as well.  After they are all loaded, everything is
resolved, but they are so interdependent that there is no order
they can be loaded in without at least a couple (temporarily) unresolved
symbols, so forcing all symbols to be resolved immediately simply doesn't
work, and X will fail to start with an error about unresolved symbols.

There are two possible fixes.  One is to simply remember which packages
won't work (simple since it's just two), and always either comment out
your LDFLAGS line before merging them, or use 

LDFLAGS="" emerge xorg-server

(and the same for xf86-drivers-ati or whatever your video driver is).  The
second is to add a simple filter-ldflags call to the ebuild's
package_setup() function.  Here's the patch I filed for xorg-server:

--- xorg-server-1.0.99.903.ebuild       2006-05-13 08:36:22.000000000 -0700
+++ xorg-server-1.0.99.903.ebuild.new   2006-05-14 03:57:03.000000000 -0700
@@ -519,6 +519,9 @@ pkg_setup() {
        # (#121394) Causes window corruption
        filter-flags -fweb

+       # (#116698) breaks loading
+       filter-ldflags -Wl,-z,now
+
        # Nothing else provides new enough glxtokens.h
        ewarn "Forcing on xorg-x11 for new enough glxtokens.h..."
        OLD_IMPLEM="$(eselect opengl show)"

You'll notice the bug number listed, but here's a link:

http://bugs.gentoo.org/show_bug.cgi?id=116698

If nothing else, it makes for interesting reading (for those into this
sort of thing <g>), with further links to the hardened bug it was
originally called a duplicate of, and to a related discussion on the
gentoo-devel list.  My main point was that while it's one thing to say
"don't use those flags then", it's quite another to say that when portage
itself is saying to use them, when merging that very package!  When
those only following the instructions output by portage when merging a
package end up with a broken installation as a result, the ebuild
shouldn't be cleared for stabilization (a certain amount of such things
might be expected in ~arch, but not for stable).  The bug, BTW, is marked
resolved/fixed, altho the fix to the ebuild wasn't quite the same as my
suggested patch and I've not yet verified that it indeed totally solves
the problem, as I had with my patch.

Anyway, since the ldflags I use cause can cause occasional problems, and
aren't much more than a personal preference thing with real tradeoffs even
when they work, it's not something I can recommend, but it's something
that works for me, and since you asked about what people had for their
ldflags and why, I thought I'd answer.

As for other LDFLAGS, I too haven't found a lot on them.  Since I
believe the advice elsewhere to only use them if you know what you are
doing, and I don't know enough about any others to be confident using
them, I don't.



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list