public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Edelsohn <dje.gcc@gmail.com>
To: Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s
Date: Fri, 07 Nov 2014 19:52:00 -0000	[thread overview]
Message-ID: <CAGWvnynSPN4aAugugjVhZCOBBzTLpVw4VoZGFkef+nQqKAkFWQ@mail.gmail.com> (raw)

First, please explicitly copy me on AIX or PowerPC patches sent to gcc-patches.

I don't have a fundamental objection to including this option, but
note that Richi, Honza and I have discovered that using AIX runtime
linking option interacts badly with some GCC optimizations and can
result in applications that hang in a loop.

All code on AIX is position independent (PIC) by default.  Executables
and shared libraries essentially are PIE.  Because of this, AIX does
not provide separate "static" libraries and one can link statically
with a shared library.

Creating a library enabled for runtime linking with -G (-brtl), causes
a lot of problems, including a newly recognized failure mode.  Without
careful control over AIX symbol export, all global calls with use
glink code (equivalent to ELF PLTs). This also creates a TOC entry for
every global call, possibly overflowing the TOC.

But the main problem is GCC uses aliases and functions declared as
weak to support some C++ features. Functions declared weak interact
badly with shared libraries compiled for AIX runtime linking and
linked statically.  This can result in the static binary binding with
the glink code that loads its own address from the TOC instead of the
target function, causing endless looping.  Honza made some changes to
GCC code generation for AIX, but there still are problems and I have
disabled building libstdc++ enabled for runtime linking.

libgcc always explicitly creates a static library and uses it for
static linking.  All shared libraries for AIX that use this scheme
(through libtool) would have to follow the same convention to create
both shared and static libraries.  This new option only makes sense if
it fully emulates SVR4/ELF behavior and always creates both shared .so
and static .a libraries.

Thanks, David

             reply	other threads:[~2014-11-07 19:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-07 19:52 David Edelsohn [this message]
2014-11-10 10:01 ` Michael Haubenwallner
2014-11-10 16:17   ` David Edelsohn
2014-11-10 18:01     ` Michael Haubenwallner
2014-11-11 15:03       ` David Edelsohn
2014-11-11 15:44         ` Michael Haubenwallner
2014-11-25 14:25           ` David Edelsohn
2014-12-05 12:56             ` Michael Haubenwallner
2014-12-05 14:06               ` David Edelsohn
  -- strict thread matches above, loose matches on Subject: below --
2014-11-07 12:58 Michael Haubenwallner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGWvnynSPN4aAugugjVhZCOBBzTLpVw4VoZGFkef+nQqKAkFWQ@mail.gmail.com \
    --to=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=michael.haubenwallner@ssi-schaefer.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).