Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Nov 2011 06:05:13 +0400
From: Solar Designer <>
Subject: Re: %optflags for new gcc

On Fri, Nov 04, 2011 at 04:37:31AM +0400, Solar Designer wrote:
> As to libraries, things are trickier: some might have callbacks, and we
> have no control over how third-party binaries are compiled (some may
> expect their called back functions to have 16-byte stack alignment).

So I just ran into this problem with my own code, not even on purpose.
Spent some time debugging it, even.  Apparently, libgomp has callbacks
back into the main OpenMP-using program.  For thread 0, I am getting
properly 16-byte aligned %esp (my program is compiled without any
-mpreferred-stack-boundary option, so the default of "4" is used).  For
thread 1, I got 0xb7c3b414 as address of one of the vector-typed
variables on the stack.  (I introduced the variable just to check its
address; without that, I was getting segfaults from accesses to gcc's
temporaries, which it allocated and put on the stack on its own when it
ran out of SSE registers for some calculations.)

For gcc, we make an attempt to use %optflags_lib for its libraries:


%__make bootstrap-lean \
	STAGE1_CFLAGS="-O -fomit-frame-pointer" \
	BOOT_CFLAGS="-O -fomit-frame-pointer" \

However, apparently this did not work at least for libgomp - notice how
the address I got is not even 8-byte aligned, which it would be if our
current %optflags_lib had worked.

We'll need to investigate and fix this.


Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ