This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH,rs6000] fix bugs with out-of-line prologues/epilogues, take 2


On Wed, Nov 19, 2008 at 01:16:43PM -0800, Nathan Froyd wrote:
> This patch is a repost of:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01375.html
> 
> with more bugs flushed--in particular, the bootstrap problems reported:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00047.html
> 
> should be fixed.

David asked me to rebuild and retest on powerpc64-unknown-linux-gnu
using {GP,FP}_SAVE_INLINE from config/rs6000/aix.h to ensure that the
aforementioned bootstrap problems went away.  They did go away--after
flushing another small bug--but turned up a more interesting problem
that I'm not quite sure how to solve.

(A bit of background: the rs6000 backend has logic to emit calls to
out-of-line register save/restore routines.  Target platforms can
control how often these routines get used through the
{GP,FP}_SAVE_INLINE macros: 32-bit SVR4 derivatives use the routines
when optimizing for size, AIX uses the out-of-line floating-point save
routines quite frequently, and Darwin eschews the routines entirely.
These functions use a non-standard calling convention and are placed in
libgcc.a and marked as .hidden to avoid problems with dynamic libraries
and symbol resolution.)

The problem is this: during compilation of several g++ testcases with
-m32, we get errors about:

$MUMBLE/ld: $MUMBLE/g++-bprob-1.x01: hidden symbol `_restfpr_14_x' in $MUMBLE/libgcc.a(crtresxfpr.o) is referenced by DSO

This sort of problem was supposed to be fixed with r141090, which added
.hidden declarations to all the out-of-line functions.

What happens is that since the aix.h {GP,FP}_SAVE_INLINE macros are
willing to save registers out-of-line at all optimization settings--not
just -Os, like their counterparts in svr4.h--some of the libstdc++
sources are compiled to use the out-of-line save/restore functions.
However, when libstdc++ is linked, it links against libgcc_s.so, but not
libgcc.a.  The references to out-of-line functions in libstdc++ objects
are not resolved against libgcc.a (where the functions normally reside),
nor are they resolved against libgcc_s.so (because the out-of-line
save/restore routines are hidden symbols).  libstdc++ winds up with
undefined symbols that no shared library is going to resolve and can't
be linked along with libgcc.a, because then we are attempting to resolve
symbols in libstdc++ against hidden symbols in libgcc.a and doing that
produces the error message shown above.

(Suddenly the choice of the linker providing these functions on
powerpc64 is starting to make more sense.)

Notice that this also affects any configs built with
config/rs6000/svr4.h as well.  However, since libstdc++ isn't usually
compiled with -Os, calls to the out-of-line routines are not (usually)
used and the problem never surfaces.

>From what I can gather, not linking libstdc++ against libgcc.a is a
deliberate decision, so the burden of resolving the problem falls to the
powerpc backend.  Furthermore, IIUC, this is a failure mode that could
easily be seen in the real world if C++ libraries compile with -Os and
link with -shared-libgcc.  What's the right thing to do here?  How does
AIX avoid the same sort of problem?

-Nathan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]