public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: ian@airs.com (Ian Lance Taylor)
Cc: hans-peter.nilsson@axis.com (Hans-Peter Nilsson),
	fxcoudert@gmail.com,        gcc-patches@gcc.gnu.org,
	ubizjak@gmail.com, fortran@gcc.gnu.org
Subject: Re: Fix libbacktrace -fPIC breakage from "Use libbacktrace in libgfortran"
Date: Tue, 25 Aug 2015 13:25:00 -0000	[thread overview]
Message-ID: <20150825125905.7F12F247E@oc7340732750.ibm.com> (raw)
In-Reply-To: <m3h9nob0j1.fsf@pepe.airs.com> from "Ian Lance Taylor" at Aug 24, 2015 06:49:06 PM

Ian Lance Taylor wrote:
> Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
> 
> > 	* configure.ac: Only compile with -fPIC if the target
> > 	supports it.
> > 	* configure: Regenerate.
> 
> This is OK.

I'm now running into the same problem on SPU, but unfortnately
this patch still doesn't fix the problem.

Now, the SPU does not support dynamic loading and the loader
does not support (most) run-time relocations.  There is no
support for shared libraries on the SPU.  On the SPU, all
GCC target libraries are built as static libraries, and
should be compiled without -fPIC.

However, the compiler actually does accept -fPIC.  If the flag is
present, we attempt to generate relocatable code, but only to the
extent the compiler can do that without support for run-time
relocations.  The most significant restriction is that statically
initializing a global variable to a pointer will not work.
(This is useful for some special cases of self-relocating code.
Such code normally can work around this restriction.)

Now, with the patch above, libbacktrace is still compiled with
-fPIC on SPU, but some files do in fact contain just such global
initializers, causing compilation to fail:

gcc-head/src/libbacktrace/elf.c:241:27: error: creating run-time relocation for '*.LC2'
 static const char * const debug_section_names[DEBUG_MAX] =
                           ^
The other GCC run-time libraries rely on libtool to figure out
that even though -fPIC works, dynamic libraries are still not
supported on the platform, and thus compile everything for
static linking (i.e. without -fPIC).

I'm wondering if we couldn't use the same libtool mechanism here:
if the architecture does not support dynamic linking at all, no
target library will be built as shared library, and thus there is
no need to build libbacktrace with -fPIC either.  (My understanding
is that we need to build libbacktrace with -fPIC because it might
get linked into some other shared target library.)

The libbacktrace configure script actually incorporates all the
libtool init code that makes this determination, and sets the
shell variable "can_build_shared" to "no" on SPU.  Would it be
valid to use this variable in the test whether to use -fPIC?
(I'm not sure which of the many libtool variables are intended
to be used outside, and which are private ...)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

  reply	other threads:[~2015-08-25 13:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-14 13:19 [patch,libgfortran,toplevel] Use libbacktrace in libgfortran Uros Bizjak
2015-08-14 14:31 ` FX
2015-08-23 20:14   ` Janne Blomqvist
2015-08-23 20:59     ` FX
2015-08-23 21:27       ` Janne Blomqvist
2015-08-24  7:15         ` FX
2015-08-24 16:00   ` Fix libbacktrace -fPIC breakage from "Use libbacktrace in libgfortran" Hans-Peter Nilsson
2015-08-24 16:08     ` FX
2015-08-24 16:44       ` Hans-Peter Nilsson
2015-08-24 18:42         ` FX
2015-08-25  3:29         ` Ian Lance Taylor
2015-08-25 13:25           ` Ulrich Weigand [this message]
2015-08-25 17:09             ` Hans-Peter Nilsson
2015-08-25 17:57               ` Ulrich Weigand
2015-08-26  0:09                 ` Hans-Peter Nilsson
2015-08-26 12:17                   ` Ulrich Weigand
2015-08-26 12:34                     ` Hans-Peter Nilsson
2015-08-26 15:37                       ` [PATCH] Fix and simplify (Re: Fix libbacktrace -fPIC breakage from "Use libbacktrace in libgfortran") Ulrich Weigand
2015-08-27  4:02                         ` Ian Lance Taylor
2015-08-27 13:38                           ` Ulrich Weigand
2015-08-27 14:02                             ` Ian Lance Taylor
2015-08-24 16:04   ` Fix libbacktrace -fPIC breakage from "Use libbacktrace in libgfortran" Hans-Peter Nilsson

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=20150825125905.7F12F247E@oc7340732750.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=fortran@gcc.gnu.org \
    --cc=fxcoudert@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hans-peter.nilsson@axis.com \
    --cc=ian@airs.com \
    --cc=ubizjak@gmail.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).