Use of -fPIC on Tru64

Use of -fPIC on Tru64

[Arnaud Charlet]

Hi there,

I was wondering why on Dec Unix/Tru64, GCC now includes -fPIC in
TARGET_LIBGCC2_FLAGS.

This was not the case with GCC 2.8.1, and as far as I understood, position
independent code is part of the ABI. So I guess I am missing something because
I do not understand why -fPIC is specified explicitely.

Could you clarify this issue ?

Arno

Re: Use of -fPIC on Tru64

[Richard Henderson]

On Thu, Dec 13, 2001 at 10:29:08AM +0100, Arnaud Charlet wrote:
> I do not understand why -fPIC is specified explicitely.

-fPIC affects assumptions about how names bind.

Without pic, it is assumed that

  void foo() { ... }
  void bar() { foo(); }

bar calls the version of foo immediately above.  With pic, this
is not a valid assumption, because the name foo may bind from
another library earlier in the search order.


r~

Re: Use of -fPIC on Tru64

[Arnaud Charlet]

> -fPIC affects assumptions about how names bind.

Thanks. So -fPIC has indeed an effect on Tru64, and generates, I guess,
less efficient code.

> Without pic, it is assumed that
> 
>   void foo() { ... }
>   void bar() { foo(); }
> 
> bar calls the version of foo immediately above.  With pic, this
> is not a valid assumption, because the name foo may bind from
> another library earlier in the search order.

But then, why does libgcc need to be compiled with -fPIC on Tru64 ?

Arno

Re: Use of -fPIC on Tru64

[Richard Henderson]

On Thu, Dec 13, 2001 at 10:44:46AM +0100, Arnaud Charlet wrote:
> But then, why does libgcc need to be compiled with -fPIC on Tru64 ?

For the same reason it has to be compiled with -fPIC on
other platforms -- so that it can be included in shared
libraries.


r~

Re: Use of -fPIC on Tru64

[Arnaud Charlet]

> > But then, why does libgcc need to be compiled with -fPIC on Tru64 ?
> 
> For the same reason it has to be compiled with -fPIC on
> other platforms -- so that it can be included in shared
> libraries.

I'm sorry, but I am still missing something.
From what you said, -fPIC on Tru64 only changes behavior of functions
inside the same object. Why do functions inside same objects for libgcc need
to be compiled with -fPIC ? That does not seem necessary to me.

Arno

Re: Use of -fPIC on Tru64

[Richard Henderson]

On Thu, Dec 13, 2001 at 06:27:09PM +0100, Arnaud Charlet wrote:
> From what you said, -fPIC on Tru64 only changes behavior of functions
> inside the same object. Why do functions inside same objects for libgcc need
> to be compiled with -fPIC ? That does not seem necessary to me.

Really I don't think it matters one way or another.  I'd rather
treat Tru64 just like every other platform and use -fPIC.


r~

Re: Use of -fPIC on Tru64

[Arnaud Charlet]

> Really I don't think it matters one way or another.  I'd rather
> treat Tru64 just like every other platform and use -fPIC.

Well, not all platforms require -fPIC, so I don't find this argument very
convincing ;-) It seems cleaner to me to avoid using -fPIC when it is not
needed.

Arno

Re: Use of -fPIC on Tru64

[Joerg Faschingbauer]

From: Arnaud Charlet <charlet@ACT-Europe.FR>
Subject: Re: Use of -fPIC on Tru64
Date: Thu, 13 Dec 2001 18:50:01 +0100

> > Really I don't think it matters one way or another.  I'd rather
> > treat Tru64 just like every other platform and use -fPIC.
> 
> Well, not all platforms require -fPIC, so I don't find this argument very
> convincing ;-) It seems cleaner to me to avoid using -fPIC when it is not
> needed.

The Linux dynamic loader implements loading non-PIC code. What you
lose though is sharing of text pages because text has to be patched
then.

Joerg

Re: Use of -fPIC on Tru64

[Arnaud Charlet]

> The Linux dynamic loader implements loading non-PIC code. What you
> lose though is sharing of text pages because text has to be patched
> then.

What does this have to do with Tru64 where position independent code is part
of the ABI ?

I appreciate and understand the motivation on systems such as Linux, but
Tru64 is very different in this respect, and I still haven't seen a good
argument to enable -fPIC on Tru64 for libgcc.

Arno

Re: Use of -fPIC on Tru64

[Joerg Faschingbauer]

> > The Linux dynamic loader implements loading non-PIC code. What you
> > lose though is sharing of text pages because text has to be patched
> > then.
> 
> What does this have to do with Tru64 where position independent code is part
> of the ABI ?
> 
> I appreciate and understand the motivation on systems such as Linux, but
> Tru64 is very different in this respect, and I still haven't seen a good
> argument to enable -fPIC on Tru64 for libgcc.

The message I replied to was something along "There are
implementations where you do not need PIC to load a shared library, so
there is no need to require PIC". You didn't say anything about Tru64
(though you did in a previous message), and I was nitpicking. Kind of.

Joerg

Re: Use of -fPIC on Tru64

[Jeff Sturm]

On Tue, 18 Dec 2001, Arnaud Charlet wrote:
> I appreciate and understand the motivation on systems such as Linux, but
> Tru64 is very different in this respect, and I still haven't seen a good
> argument to enable -fPIC on Tru64 for libgcc.

Perhaps.  But I haven't seen a good reason to disable it either.  Why make
the build system any more complicated than it need be, for goodness sake?

Jeff

Re: Use of -fPIC on Tru64

[Arnaud Charlet]

> The message I replied to was something along "There are
> implementations where you do not need PIC to load a shared library, so
> there is no need to require PIC". You didn't say anything about Tru64
> (though you did in a previous message), and I was nitpicking. Kind of.

Well obviousely this is non very helpful and non constructive, since the
subject line of this thread couldn't be clearer. Also if I were to
nitpick, I would say that you didn't read the message you quoted very carefully
because I said "shared library", and not "dynamic library", but I won't.

I guess if noone answered that nobody is really interested in discussing it.

I still haven got a clear answer as to why this change has been made in GCC.

Was it a deliberate choice, or a general change ?

As a result of this change, we can no longer rely on LIBGCC2_FLAGS to build
other shared libraries in GCC (e.g for GNAT) in a simple way on Tru64, which
is inconvenient, but I guess unavoidable.

So let me phrase my question differently: is there a configure flag/setting
that can be reused in Makefiles to know whether a target absolutely
needs -fPIC to build a shared library ?

Arno