Re: A patch for PIC default

Re: A patch for PIC default

[Ulrich Drepper]

hjl@lucon.org (H.J. Lu) writes:

> It seems to work for me. I removed the change to sysdeps/i386/bits/string.h.
> It is correct since it is the installed header file and __PIC__ is defined
> when -fPIC is used. I will send a patch for linuxthreads later.

Thanks for your efforts.  I have a few problems, though.

I understand the reason why these changes are necessary.  The questions are:

- why introducing yet another symbol SHARED?

- some files do have a different form .o and .os even for platforms where
  PIC is the default.  These files are all those which include versioning
  code.


Therefore I think the correct change is this:

- remove defining PIC from the CFLAGS-.o  This cannot make any sense.

- somehow mark those object files which contain versioning stuff and
  therefore are only used in the shared object.


This way we can build a libc.a and libc_pic.a.  Both files mainly
contain the .o files but libc_pic.a has those .o files replaced by .os
files if they contain versioning information.

I think this is only an optimization and therefore will not be added
before 2.1.  Anybody volunteer to make such a patch for later?

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: A patch for PIC default

[H.J. Lu]

> 
> hjl@lucon.org (H.J. Lu) writes:
> 
> > It seems to work for me. I removed the change to sysdeps/i386/bits/string.h.
> > It is correct since it is the installed header file and __PIC__ is defined
> > when -fPIC is used. I will send a patch for linuxthreads later.
> 
> Thanks for your efforts.  I have a few problems, though.
> 
> I understand the reason why these changes are necessary.  The questions are:
> 
> - why introducing yet another symbol SHARED?
> 

The problem is you don't have to do PIC on a processor in the static
binary. PIC is more a calling convention. It is possible for different
OSes for the same CPU not to use PIC in the static binary. Depending
on the calling convention, you have to add -DPIC when compiling the
static binary for one OS and not to add it for the other. I believe
MIPS is such an example.


H.J.

Re: A patch for PIC default

[H.J. Lu]

> > PIC is more a calling convention. It is possible for different
> > OSes for the same CPU not to use PIC in the static binary. Depending
> > on the calling convention, you have to add -DPIC when compiling the
> > static binary for one OS and not to add it for the other. I believe
> > MIPS is such an example.
> 
> This will only have an effect for assembler files.  There are not many
> of them.  For those which are there one could create separate version,
> maybe in a subdir named after this calling convention:
> 

Glibc assumes PIC means for shared libraries. It is not always correct.
PIC is a calling convention. It can be used for shared libraries as
well as static libraries. That is what Ralf tried to fix. He used
SHARED for shared libraries. Otherwise, you will get confused yourself.



-- 
H.J. Lu (hjl@gnu.org)

Re: A patch for PIC default

[Ulrich Drepper]

hjl@lucon.org (H.J. Lu) writes:

> Glibc assumes PIC means for shared libraries. It is not always correct.

Right.  PIC means shared lib, and most probably (unless I miss
something) always shared lib (unless when used in assembler code).

But this shouldn't be a problem.  On systems where static code is not
compiled the same way as PIC the distinction is what we want.  Again,
this is only for assembler code and versioning stuff.

For systems which use the same code (e.g., MIPS) there is no need to
compile any file using PIC except it depends on this symbol for
generating versioning information.  There will not be assembler code
depending on this symbol.  And for the versioning information case I
suggested to provide a way to generate the .os files which then would
get the -DPIC on the commandline.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: A patch for PIC default

[Ulrich Drepper]

hjl@lucon.org (H.J. Lu) writes:

> The problem is you don't have to do PIC on a processor in the static
> binary.

I know.

> PIC is more a calling convention. It is possible for different
> OSes for the same CPU not to use PIC in the static binary. Depending
> on the calling convention, you have to add -DPIC when compiling the
> static binary for one OS and not to add it for the other. I believe
> MIPS is such an example.

This will only have an effect for assembler files.  There are not many
of them.  For those which are there one could create separate version,
maybe in a subdir named after this calling convention:

	sysdeps/mips/no-pic-in-static

I really want to avoid having even more macros controlling things like
this.  It's not necessary and only can add to confusion.

Plus: there is AFAIK so far no platform which requires the other
behaviour.  Maybe there never will and then we add this extra ugliness
without reason.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: A patch for PIC default

[H.J. Lu]

> 
> hjl@lucon.org (H.J. Lu) writes:
> 
> > Glibc assumes PIC means for shared libraries. It is not always correct.
> 
> Right.  PIC means shared lib, and most probably (unless I miss
> something) always shared lib (unless when used in assembler code).
> 

What is wrong with Ralf's patch? PIC is confusing. I like SHARED. His
patch is the first step toward the right direction.

-- 
H.J. Lu (hjl@gnu.org)

Re: A patch for PIC default

[Andreas Jaeger]

Hi,

I'm bringing up an old discussion.
>>>>> Ulrich Drepper wrote on 17 Nov 1998:

Ulrich> hjl@lucon.org (H.J. Lu) writes:
>> It seems to work for me. I removed the change to sysdeps/i386/bits/string.h.
>> It is correct since it is the installed header file and __PIC__ is defined
>> when -fPIC is used. I will send a patch for linuxthreads later.

Ulrich> Thanks for your efforts.  I have a few problems, though.

Ulrich> I understand the reason why these changes are necessary.  The questions are:

Ulrich> - why introducing yet another symbol SHARED?

Ulrich> - some files do have a different form .o and .os even for platforms where
Ulrich>   PIC is the default.  These files are all those which include versioning
Ulrich>   code.

There are some files which have different .o and .os forms which
aren't dependend on versioning code.  For example elf/dl-close.c has:
#ifdef PIC
          /* We will unlink the first object only if this is a statically
             linked program.  */
          assert (imap->l_prev != NULL);
          imap->l_prev->l_next = imap->l_next;
#else
          if (imap->l_prev != NULL)
            imap->l_prev->l_next = imap->l_next;
          else
            _dl_loaded = imap->l_next;
#endif

Other C files which are effected are elf/dl-open.c,
include/libc-symbols.h (this one might be ok), libio/freopen.c,
linuxthreads/cancel.c, linuxthreads/pthread.c, nss/nsswitch.c,
sysdeps/generic/libc-start.c, sysdeps/unix/sysv/linux/init-first.c,
...

How should we handle those files?  I guess Ralf introduced SHARED also
for this problem.

Ulrich> Therefore I think the correct change is this:

Ulrich> - remove defining PIC from the CFLAGS-.o  This cannot make any sense.

Ulrich> - somehow mark those object files which contain versioning stuff and
Ulrich>   therefore are only used in the shared object.


Ulrich> This way we can build a libc.a and libc_pic.a.  Both files mainly
Ulrich> contain the .o files but libc_pic.a has those .o files replaced by .os
Ulrich> files if they contain versioning information.

Ulrich> I think this is only an optimization and therefore will not be added
Ulrich> before 2.1.  Anybody volunteer to make such a patch for later?

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de