Setting up of GP in static, non-PIC version of glibc?

Setting up of GP in static, non-PIC version of glibc?

[Hartvig Ekner]

I compiled a static, non-PIC version of glibc (from H.J's miniport SRPM)
to allow testing of MIPS16[e] apps.

One of the things that did not work, is that nobody sets up GP correctly
in this case.

Modifying "/usr/src/redhat/BUILD/glibc-2.2.4/sysdeps/mips/elf/start.S" to
setup GP:

        .text
        .globl ENTRY_POINT
        .type ENTRY_POINT,@function
ENTRY_POINT:
#ifdef __PIC__
        SET_GP
#else
        la  $28, _gp
#endif

Makes things work (this code ends in crt1.o). Is this the right place to 
fix it?

/Hartvig

Re: Setting up of GP in static, non-PIC version of glibc?

[Ralf Baechle]

On Mon, Feb 25, 2002 at 04:16:20PM +0100, Hartvig Ekner wrote:

>         .globl ENTRY_POINT
>         .type ENTRY_POINT,@function
> ENTRY_POINT:
> #ifdef __PIC__
>         SET_GP
> #else
>         la  $28, _gp
> #endif
> 
> Makes things work (this code ends in crt1.o). Is this the right place to 
> fix it?

Non-PIC code doesn't use $gp, so any reference to $gp is a bug.  Note
that we don't support global data optimization for ELF either that is,
-G 0 is the default.

  Ralf

Re: Setting up of GP in static, non-PIC version of glibc?

[Johannes Stezenbach]

On Mon, Feb 25, 2002 at 05:34:33PM +0100, Ralf Baechle wrote:
> On Mon, Feb 25, 2002 at 04:16:20PM +0100, Hartvig Ekner wrote:
> 
> >         .globl ENTRY_POINT
> >         .type ENTRY_POINT,@function
> > ENTRY_POINT:
> > #ifdef __PIC__
> >         SET_GP
> > #else
> >         la  $28, _gp
> > #endif
> > 
> > Makes things work (this code ends in crt1.o). Is this the right place to 
> > fix it?
> 
> Non-PIC code doesn't use $gp, so any reference to $gp is a bug.  Note
> that we don't support global data optimization for ELF either that is,
> -G 0 is the default.

I recently experimented with dietlibc and tried to create
static, non-PIC binaries, with some success.
Contradicting the docs (gcc info), -G 0 is not the default but
has to be passed explicitely (even when using the GNU assembler).

BTW: Who is "we"? Do you mean global data optimization is broken
in gcc/binutils or just that no one at SGI is using it?


Regards,
Johannes

Re: Setting up of GP in static, non-PIC version of glibc?

[Ralf Baechle]

On Mon, Feb 25, 2002 at 07:31:41PM +0100, Johannes Stezenbach wrote:

> > 
> > Non-PIC code doesn't use $gp, so any reference to $gp is a bug.  Note
> > that we don't support global data optimization for ELF either that is,
> > -G 0 is the default.
> 
> I recently experimented with dietlibc and tried to create
> static, non-PIC binaries, with some success.
> Contradicting the docs (gcc info), -G 0 is not the default but
> has to be passed explicitely (even when using the GNU assembler).

It always was until somebody broke gcc.

> BTW: Who is "we"? Do you mean global data optimization is broken
> in gcc/binutils or just that no one at SGI is using it?

It's an ECOFF specific optimization that just has been forward ported into
the ELF world.  And what does this have to do with SGI anyway?

  Ralf

Re: Setting up of GP in static, non-PIC version of glibc?

[Hartvig Ekner]

Ralf Baechle writes:
> 
> On Mon, Feb 25, 2002 at 07:31:41PM +0100, Johannes Stezenbach wrote:
> > BTW: Who is "we"? Do you mean global data optimization is broken
> > in gcc/binutils or just that no one at SGI is using it?
> 
> It's an ECOFF specific optimization that just has been forward ported into
> the ELF world.  And what does this have to do with SGI anyway?

I still don't get it. Why would one not use GP optimization with non-shared
non-PIC code? It certainly is used throughout in the non-Linux MIPS world,
and on the limited testing I did today it also worked fine. Is there 
something which is known not to work, or some conflict somewhere which
prevents the general use of GP?

/Hartvig

Re: Setting up of GP in static, non-PIC version of glibc?

[Hartvig Ekner]

Ralf Baechle writes:
> 
> On Mon, Feb 25, 2002 at 07:31:41PM +0100, Johannes Stezenbach wrote:
> > BTW: Who is "we"? Do you mean global data optimization is broken
> > in gcc/binutils or just that no one at SGI is using it?
> 
> It's an ECOFF specific optimization that just has been forward ported into
> the ELF world.  And what does this have to do with SGI anyway?

I still don't get it. Why would one not use GP optimization with non-shared
non-PIC code? It certainly is used throughout in the non-Linux MIPS world,
and on the limited testing I did today it also worked fine. Is there 
something which is known not to work, or some conflict somewhere which
prevents the general use of GP?

/Hartvig

Re: Setting up of GP in static, non-PIC version of glibc?

[Johannes Stezenbach]

On Mon, Feb 25, 2002 at 07:39:28PM +0100, Ralf Baechle wrote:
> On Mon, Feb 25, 2002 at 07:31:41PM +0100, Johannes Stezenbach wrote:
> > BTW: Who is "we"? Do you mean global data optimization is broken
> > in gcc/binutils or just that no one at SGI is using it?
> 
> It's an ECOFF specific optimization that just has been forward ported into
> the ELF world.  And what does this have to do with SGI anyway?

I was wondering who you speak for when you say "we don't
support foobar", and your email is @oss.sgi.com.

I was just trying to decode the meaning of what you said.
Like, did you mean "I don't care about it" or "The tools are
totally broken and you have to go along way to use it"?

The global data optimization would fit dietlibc's goal
of as-small-as-possible, statically linked binaries. But
from what you said I gather I would have to fix gcc and
binutils first.


Johannes

Re: Setting up of GP in static, non-PIC version of glibc?

[Ralf Baechle]

On Mon, Feb 25, 2002 at 08:21:00PM +0100, Hartvig Ekner wrote:

> > > BTW: Who is "we"? Do you mean global data optimization is broken
> > > in gcc/binutils or just that no one at SGI is using it?
> > 
> > It's an ECOFF specific optimization that just has been forward ported into
> > the ELF world.  And what does this have to do with SGI anyway?
> 
> I still don't get it. Why would one not use GP optimization with non-shared
> non-PIC code? It certainly is used throughout in the non-Linux MIPS world,
> and on the limited testing I did today it also worked fine. Is there 
> something which is known not to work, or some conflict somewhere which
> prevents the general use of GP?

I thought gcc would would for no good reason plain refuse to use global
pointer optimization with ELF - but I was wrong, just tested it again.
I also noticed that older gcc would emit initialized data to .data with
-G even though small data should go to .sdata.

Won't work by just enabeling for the kernel though.  The kernel has it's
own idea of how to use the $gp register.

  Ralf

Re: Setting up of GP in static, non-PIC version of glibc?

[Ralf Baechle]

On Mon, Feb 25, 2002 at 08:32:50PM +0100, Johannes Stezenbach wrote:

> > It's an ECOFF specific optimization that just has been forward ported into
> > the ELF world.  And what does this have to do with SGI anyway?
> 
> I was wondering who you speak for when you say "we don't
> support foobar", and your email is @oss.sgi.com.

You seem to be unaware that half of oss users are ex-sgi employees :-)

> I was just trying to decode the meaning of what you said.
> Like, did you mean "I don't care about it" or "The tools are
> totally broken and you have to go along way to use it"?
> 
> The global data optimization would fit dietlibc's goal
> of as-small-as-possible, statically linked binaries. But
> from what you said I gather I would have to fix gcc and
> binutils first.

See also my other email about the status of -G.

  Ralf

Re: Setting up of GP in static, non-PIC version of glibc?

[Jay Carlson]

On Monday, February 25, 2002, at 11:34 AM, Ralf Baechle wrote:

> On Mon, Feb 25, 2002 at 04:16:20PM +0100, Hartvig Ekner wrote:
>
>>         .globl ENTRY_POINT
>>         .type ENTRY_POINT,@function
>> ENTRY_POINT:
>> #ifdef __PIC__
>>         SET_GP
>> #else
>>         la  $28, _gp
>> #endif
>>
>> Makes things work (this code ends in crt1.o). Is this the right place 
>> to
>> fix it?
>
> Non-PIC code doesn't use $gp, so any reference to $gp is a bug.  Note
> that we don't support global data optimization for ELF either that is,
> -G 0 is the default.

By default non-PIC code *does* use $gp due to the brain damage in gas; 
gas defaults to -G 8 unless told otherwise (-KPIC implies -G0 so we 
don't see this in PIC code.)  gcc won't know anything about this, of 
course.

What I'm doing in SUBTARGET_ASM_SPEC is to write something like 
"%{fno-pic: %{!G: -G0}}"--if we're not in PIC mode, pass -G0 to gas by 
default.

Anyway, once that's straightened out, -G8 does appear to work the way 
you'd expect, with the code that Hartvig pasted above---I had written a 
byte-for-byte identical patch :-)

Jay

Re: Setting up of GP in static, non-PIC version of glibc?

[Ralf Baechle]

On Tue, Feb 26, 2002 at 12:10:50AM -0500, Jay Carlson wrote:

> By default non-PIC code *does* use $gp due to the brain damage in gas; 
> gas defaults to -G 8 unless told otherwise (-KPIC implies -G0 so we 
> don't see this in PIC code.)  gcc won't know anything about this, of 
> course.
> 
> What I'm doing in SUBTARGET_ASM_SPEC is to write something like 
> "%{fno-pic: %{!G: -G0}}"--if we're not in PIC mode, pass -G0 to gas by 
> default.
> 
> Anyway, once that's straightened out, -G8 does appear to work the way 
> you'd expect, with the code that Hartvig pasted above---I had written a 
> byte-for-byte identical patch :-)

I agree on that one except that 64kB of small data no longer seem to be
sufficient for every common application in the world.  So I'd vote for a
more defensive choice of the -G value, that is 0.

  Ralf

Re: Setting up of GP in static, non-PIC version of glibc?

[Jay Carlson]

On Tuesday, February 26, 2002, at 06:55 AM, Ralf Baechle wrote:

> On Tue, Feb 26, 2002 at 12:10:50AM -0500, Jay Carlson wrote:
>
>> By default non-PIC code *does* use $gp due to the brain damage in gas;
>> gas defaults to -G 8 unless told otherwise (-KPIC implies -G0 so we
>> don't see this in PIC code.)  gcc won't know anything about this, of
>> course.
>>
>> What I'm doing in SUBTARGET_ASM_SPEC is to write something like
>> "%{fno-pic: %{!G: -G0}}"--if we're not in PIC mode, pass -G0 to gas by
>> default.
>>
>> Anyway, once that's straightened out, -G8 does appear to work the way
>> you'd expect, with the code that Hartvig pasted above---I had written a
>> byte-for-byte identical patch :-)
>
> I agree on that one except that 64kB of small data no longer seem to be
> sufficient for every common application in the world.  So I'd vote for a
> more defensive choice of the -G value, that is 0.

Right.  In my ideal world, here's how it would work:

cc1 defaults to -G0.  I think we have that now.

gas defaults to -G0.  Messing with SUBTARGET_ASM_SPEC has that effect 
for people who use the gcc driver, but anybody invoking gas directly 
will still hit this problem, but too bad.

So I think the primary constituency for gas defaulting to -G8 are 
existing cygnuhhhh I mean redhat embedded MIPS customers, outside of 
Linux; that's who we should check with before we change the default.

Jay

Re: Setting up of GP in static, non-PIC version of glibc?

[Ralf Baechle]

On Tue, Feb 26, 2002 at 09:55:30AM -0500, Jay Carlson wrote:

> Right.  In my ideal world, here's how it would work:
> 
> cc1 defaults to -G0.  I think we have that now.
> 
> gas defaults to -G0.  Messing with SUBTARGET_ASM_SPEC has that effect 
> for people who use the gcc driver, but anybody invoking gas directly 
> will still hit this problem, but too bad.
> 
> So I think the primary constituency for gas defaulting to -G8 are 
> existing cygnuhhhh I mean redhat embedded MIPS customers, outside of 
> Linux; that's who we should check with before we change the default.

So far we've been following the MIPS-UNIX tradition more than anything
else.

  Ralf

Re: Setting up of GP in static, non-PIC version of glibc?

[Hartvig Ekner]

Hi,

On Tue, Feb 26, 2002 at 09:55:30AM -0500, Jay Carlson wrote:
> Right.  In my ideal world, here's how it would work:
> 
> cc1 defaults to -G0.  I think we have that now.
> 
> gas defaults to -G0.  Messing with SUBTARGET_ASM_SPEC has that effect 
> for people who use the gcc driver, but anybody invoking gas directly 
> will still hit this problem, but too bad.
> 
> So I think the primary constituency for gas defaulting to -G8 are 
> existing cygnuhhhh I mean redhat embedded MIPS customers, outside of 
> Linux; that's who we should check with before we change the default.

We cannot change the default for non-Linux MIPS users without causing
massive problems. As far as I know, everybody uses -G8 as the default,
which can include such things as libraries (which may be delivered as
binary only).

So this is probably one of these things where the Linux/MIPS world will
do one thing, and the rest something else.

/Hartvig