libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Martin v. Loewis]

Further analysis shows that the incompatibility was caused due to
different binutils versions. On the system where the binary was
compiled, binutils 2.12 was present, which has --eh-frame-hdr.

On the system where the binary was run, binutils 2.11 was present,
which does not support this option.

So binutils versions that differ by one minor can cause binary
incompatibilities for C++ :-(

Regards,
Martin

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 06:43:17AM +0200, Martin v. Loewis wrote:
> Further analysis shows that the incompatibility was caused due to
> different binutils versions. On the system where the binary was
> compiled, binutils 2.12 was present, which has --eh-frame-hdr.
> 
> On the system where the binary was run, binutils 2.11 was present,
> which does not support this option.
> 
> So binutils versions that differ by one minor can cause binary
> incompatibilities for C++ :-(

Here I don't understand what you mean. If one gcc was configured against
2.12 binutils (2.12.1+ or plain 2.12 (which shouldn't be used)?), then
it forever requires those binutils, as it passes --eh-frame-hdr from
specs (and relies on PT_GNU_EH_FRAME being present, so
that __register_frame* calls are not necessary in the crtstuff).
Which crtstuff is used is picked at link time and at the same time
you either pass or don't pass --eh-frame-hdr, so you either rely on
PT_GNU_EH_FRAME or don't.

	Jakub

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Martin v. Loewis]

Jakub Jelinek <jakub@redhat.com> writes:

> Here I don't understand what you mean. If one gcc was configured against
> 2.12 binutils (2.12.1+ or plain 2.12 (which shouldn't be used)?), then
> it forever requires those binutils, as it passes --eh-frame-hdr from
> specs (and relies on PT_GNU_EH_FRAME being present, so
> that __register_frame* calls are not necessary in the crtstuff).
> Which crtstuff is used is picked at link time and at the same time
> you either pass or don't pass --eh-frame-hdr, so you either rely on
> PT_GNU_EH_FRAME or don't.

What happened was this: System A has ld 2.12.90.0.14 20020627 Debian
GNU/Linux. A binary "test" is created with g++ 3.1.1 on this system
(compiled and linked).

System B has ld 2.11.92.0.10 20011021 (SuSE). g++ 3.3 20020804 is
built on this system, including libgcc_s.so.1.

The binary "test" is copied from A to B. When run on B, it crashes.

Notice that B's binutils are not used at all - this is purely an ABI
issue. Yet still their version number alone resulted in a binary
incompatibilitity - if I copy libgcc_s.so.1 from A to B also, "test"
works fine.

I'll attach the source code test.cc below.

Regards,
Martin

#include <stdio.h>
int main () {
  try {
    throw 1;
  } catch (...) {
        printf("caught\n");
  }

  return 1;
}

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 10:03:51AM +0200, Martin v. Loewis wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > Here I don't understand what you mean. If one gcc was configured against
> > 2.12 binutils (2.12.1+ or plain 2.12 (which shouldn't be used)?), then
> > it forever requires those binutils, as it passes --eh-frame-hdr from
> > specs (and relies on PT_GNU_EH_FRAME being present, so
> > that __register_frame* calls are not necessary in the crtstuff).
> > Which crtstuff is used is picked at link time and at the same time
> > you either pass or don't pass --eh-frame-hdr, so you either rely on
> > PT_GNU_EH_FRAME or don't.
> 
> What happened was this: System A has ld 2.12.90.0.14 20020627 Debian
> GNU/Linux. A binary "test" is created with g++ 3.1.1 on this system
> (compiled and linked).
> 
> System B has ld 2.11.92.0.10 20011021 (SuSE). g++ 3.3 20020804 is
> built on this system, including libgcc_s.so.1.
> 
> The binary "test" is copied from A to B. When run on B, it crashes.
> 
> Notice that B's binutils are not used at all - this is purely an ABI
> issue. Yet still their version number alone resulted in a binary
> incompatibilitity - if I copy libgcc_s.so.1 from A to B also, "test"
> works fine.
> 
> I'll attach the source code test.cc below.

The compatibility is only backward compatibility, not forward compatibility.
So if you build binaries/libraries on a system with PT_GNU_EH_FRAME capable
g++/libgcc_s, you need to use that libgcc_s wherever you run those programs.

On the other side, programs/binaries built on g++/libgcc_s not
PT_GNU_EH_FRAME aware will run against PT_GNU_EH_FRAME aware libgcc_s.

That's why I propose that in order to build g++ 3.2 interoperable with
everyone else glibc 2.2.5+, binutils 2.12.1+ and --enable-shared
--enable-threads=posix --enable-__cxa_atexit is required.
We could even cook up a testsuite which wether g++/libgcc_s/libstdc++ follow
those requiremenets.

	Jakub

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Martin v. Loewis]

Jakub Jelinek <jakub@redhat.com> writes:

> The compatibility is only backward compatibility, not forward
> compatibility.  So if you build binaries/libraries on a system with
> PT_GNU_EH_FRAME capable g++/libgcc_s, you need to use that libgcc_s
> wherever you run those programs.

Should this incompatibility be indicated in the libgcc_s version, or
in a versioned symbol?

I predict that users will get easily confused by that, and quite upset
because the failure cause is so difficult to track down. OTOH, if the
dynamic linker tells them that they need _Unwind_Find_FDE@GNU_MAGIC,
they get a clue that something is wrong with their shared libraries.

Regards,
Martin

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Richard Henderson]

On Mon, Aug 05, 2002 at 10:11:59AM +0200, Jakub Jelinek wrote:
> That's why I propose that in order to build g++ 3.2 interoperable with
> everyone else glibc 2.2.5+, binutils 2.12.1+ and --enable-shared
> --enable-threads=posix --enable-__cxa_atexit is required.
> We could even cook up a testsuite which wether g++/libgcc_s/libstdc++ follow
> those requiremenets.

I think it would be reasonable to actively fail the configure
on Linux if these requirements are not met.  Otherwise it's
sure to be the case that someone won't read this even if we
were to document it properly.

Mark, what do you think?


r~

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Daniel Jacobowitz]

On Mon, Aug 05, 2002 at 05:57:11AM -0400, Richard Henderson wrote:
> On Mon, Aug 05, 2002 at 10:11:59AM +0200, Jakub Jelinek wrote:
> > That's why I propose that in order to build g++ 3.2 interoperable with
> > everyone else glibc 2.2.5+, binutils 2.12.1+ and --enable-shared
> > --enable-threads=posix --enable-__cxa_atexit is required.
> > We could even cook up a testsuite which wether g++/libgcc_s/libstdc++ follow
> > those requiremenets.
> 
> I think it would be reasonable to actively fail the configure
> on Linux if these requirements are not met.  Otherwise it's
> sure to be the case that someone won't read this even if we
> were to document it properly.
> 
> Mark, what do you think?

As long as there is a configure option to build anyway.  That's an
awful lot of released systems you're talking about not building on!

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Richard Henderson]

On Mon, Aug 05, 2002 at 08:45:20AM -0400, Daniel Jacobowitz wrote:
> As long as there is a configure option to build anyway.  That's an
> awful lot of released systems you're talking about not building on!

So?  If you're upgrading gcc, you can upgrade binutils too.


r~

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

--On Monday, August 05, 2002 07:25:13 AM -0700 Richard Henderson 
<rth@twiddle.net> wrote:

> On Mon, Aug 05, 2002 at 08:45:20AM -0400, Daniel Jacobowitz wrote:
>> As long as there is a configure option to build anyway.  That's an
>> awful lot of released systems you're talking about not building on!
>
> So?  If you're upgrading gcc, you can upgrade binutils too.

Agreed.  On a system which supports the configury options discussed, they
should be used.

__cxa_atexit is something of a special case.  It's not really necessary
for ABI compliance; programs that mix the two methods will work, modulo
the order of calls to destructors for objects with static storage duration,
and that ordering issue was not really considered a problem for years.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Daniel Jacobowitz]

On Mon, Aug 05, 2002 at 07:31:26AM -0700, Mark Mitchell wrote:
> 
> 
> --On Monday, August 05, 2002 07:25:13 AM -0700 Richard Henderson 
> <rth@twiddle.net> wrote:
> 
> >On Mon, Aug 05, 2002 at 08:45:20AM -0400, Daniel Jacobowitz wrote:
> >>As long as there is a configure option to build anyway.  That's an
> >>awful lot of released systems you're talking about not building on!
> >
> >So?  If you're upgrading gcc, you can upgrade binutils too.
> 
> Agreed.  On a system which supports the configury options discussed, they
> should be used.

I agree with both of these statements, but as I undertstand it that's
not the whole issue.  Jakub included a glibc version in his list of
necessary infrastructure to get ABI compliance, and upgrading glibc on
a running system is very different from upgrading the compiler and
linker.  Requiring glibc 2.2.5 to build a native compiler is not OK.

How necessary it is I don't remember at the moment.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

--On Monday, August 05, 2002 10:57:58 AM -0400 Daniel Jacobowitz 
<drow@mvista.com> wrote:

> On Mon, Aug 05, 2002 at 07:31:26AM -0700, Mark Mitchell wrote:
>>
>>
>> --On Monday, August 05, 2002 07:25:13 AM -0700 Richard Henderson
>> <rth@twiddle.net> wrote:
>>
>> > On Mon, Aug 05, 2002 at 08:45:20AM -0400, Daniel Jacobowitz wrote:
>> >> As long as there is a configure option to build anyway.  That's an
>> >> awful lot of released systems you're talking about not building on!
>> >
>> > So?  If you're upgrading gcc, you can upgrade binutils too.
>>
>> Agreed.  On a system which supports the configury options discussed, they
>> should be used.
>
> I agree with both of these statements, but as I undertstand it that's
> not the whole issue.  Jakub included a glibc version in his list of
> necessary infrastructure to get ABI compliance, and upgrading glibc on
> a running system is very different from upgrading the compiler and
> linker.  Requiring glibc 2.2.5 to build a native compiler is not OK.

I think we're all in violent agreement.  Even on older systems, though,
requiring --enable-threads and such makes sense -- it's just that what
you get won't necessarily be compatible with what you get on a newer
system.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 10:57:58AM -0400, Daniel Jacobowitz wrote:
> On Mon, Aug 05, 2002 at 07:31:26AM -0700, Mark Mitchell wrote:
> > 
> > 
> > --On Monday, August 05, 2002 07:25:13 AM -0700 Richard Henderson 
> > <rth@twiddle.net> wrote:
> > 
> > >On Mon, Aug 05, 2002 at 08:45:20AM -0400, Daniel Jacobowitz wrote:
> > >>As long as there is a configure option to build anyway.  That's an
> > >>awful lot of released systems you're talking about not building on!
> > >
> > >So?  If you're upgrading gcc, you can upgrade binutils too.
> > 
> > Agreed.  On a system which supports the configury options discussed, they
> > should be used.
> 
> I agree with both of these statements, but as I undertstand it that's
> not the whole issue.  Jakub included a glibc version in his list of
> necessary infrastructure to get ABI compliance, and upgrading glibc on
> a running system is very different from upgrading the compiler and
> linker.  Requiring glibc 2.2.5 to build a native compiler is not OK.
> 
> How necessary it is I don't remember at the moment.

Necessary for eh.
If you don't upgrade glibc, you won't be able to run applications built by
others who use recent glibc (which is not about eh only, it is enough if
their program uses some function which was added only after glibc
you're using was released).
glibc 2.2.5+ is requirement when using gcc 3+ for binary compatibility
with older gcc versions anyway (otherwise older programs
cannot throw exceptions through gcc 3+ compiled libraries).

What's so hard on upgrading glibc?

	Jakub

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Daniel Jacobowitz]

On Mon, Aug 05, 2002 at 05:14:07PM +0200, Jakub Jelinek wrote:
> On Mon, Aug 05, 2002 at 10:57:58AM -0400, Daniel Jacobowitz wrote:
> > On Mon, Aug 05, 2002 at 07:31:26AM -0700, Mark Mitchell wrote:
> > > 
> > > 
> > > --On Monday, August 05, 2002 07:25:13 AM -0700 Richard Henderson 
> > > <rth@twiddle.net> wrote:
> > > 
> > > >On Mon, Aug 05, 2002 at 08:45:20AM -0400, Daniel Jacobowitz wrote:
> > > >>As long as there is a configure option to build anyway.  That's an
> > > >>awful lot of released systems you're talking about not building on!
> > > >
> > > >So?  If you're upgrading gcc, you can upgrade binutils too.
> > > 
> > > Agreed.  On a system which supports the configury options discussed, they
> > > should be used.
> > 
> > I agree with both of these statements, but as I undertstand it that's
> > not the whole issue.  Jakub included a glibc version in his list of
> > necessary infrastructure to get ABI compliance, and upgrading glibc on
> > a running system is very different from upgrading the compiler and
> > linker.  Requiring glibc 2.2.5 to build a native compiler is not OK.
> > 
> > How necessary it is I don't remember at the moment.
> 
> Necessary for eh.
> If you don't upgrade glibc, you won't be able to run applications built by
> others who use recent glibc (which is not about eh only, it is enough if
> their program uses some function which was added only after glibc
> you're using was released).
> glibc 2.2.5+ is requirement when using gcc 3+ for binary compatibility
> with older gcc versions anyway (otherwise older programs
> cannot throw exceptions through gcc 3+ compiled libraries).
> 
> What's so hard on upgrading glibc?

I don't think requiring users who want a feature of the newer compiler
to upgrade their core system library is really justified.  And on older
OS versions, or on a self-built system, it's a pretty nervous process.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 11:22:27AM -0400, Daniel Jacobowitz wrote:
> > What's so hard on upgrading glibc?
> 
> I don't think requiring users who want a feature of the newer compiler
> to upgrade their core system library is really justified.  And on older
> OS versions, or on a self-built system, it's a pretty nervous process.

Fine, but it should be made clear to them that they might have trouble
running g++ 3.2 compiled applications built by others.
Something like glibc configury which, unless --disable-sanity-checks
is given to configure, exists with error if the result would not be binary
compatible with others (such as trying to build without linuxthreads
on linux).

	Jakub

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Daniel Jacobowitz]

On Mon, Aug 05, 2002 at 11:33:25AM -0400, Jakub Jelinek wrote:
> On Mon, Aug 05, 2002 at 11:22:27AM -0400, Daniel Jacobowitz wrote:
> > > What's so hard on upgrading glibc?
> > 
> > I don't think requiring users who want a feature of the newer compiler
> > to upgrade their core system library is really justified.  And on older
> > OS versions, or on a self-built system, it's a pretty nervous process.
> 
> Fine, but it should be made clear to them that they might have trouble
> running g++ 3.2 compiled applications built by others.
> Something like glibc configury which, unless --disable-sanity-checks
> is given to configure, exists with error if the result would not be binary
> compatible with others (such as trying to build without linuxthreads
> on linux).

This idea I like a great deal.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Martin v. Loewis]

Daniel Jacobowitz <drow@mvista.com> writes:

> I agree with both of these statements, but as I undertstand it that's
> not the whole issue.  Jakub included a glibc version in his list of
> necessary infrastructure to get ABI compliance, and upgrading glibc on
> a running system is very different from upgrading the compiler and
> linker.  Requiring glibc 2.2.5 to build a native compiler is not OK.
> 
> How necessary it is I don't remember at the moment.

C++ binaries built for glibc 2.2.5 or later won't execute on a system
with glibc 2.2.4 or earlier.

Regards,
Martin

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

--On Monday, August 05, 2002 05:57:11 AM -0400 Richard Henderson 
<rth@twiddle.net> wrote:

> On Mon, Aug 05, 2002 at 10:11:59AM +0200, Jakub Jelinek wrote:
>> That's why I propose that in order to build g++ 3.2 interoperable with
>> everyone else glibc 2.2.5+, binutils 2.12.1+ and --enable-shared
>> --enable-threads=posix --enable-__cxa_atexit is required.
>> We could even cook up a testsuite which wether g++/libgcc_s/libstdc++
>> follow those requiremenets.
>
> I think it would be reasonable to actively fail the configure
> on Linux if these requirements are not met.  Otherwise it's
> sure to be the case that someone won't read this even if we
> were to document it properly.
>
> Mark, what do you think?

I agree.  I don't think we need to do this for GCC 3.2, but I do think
it would be good to do this at some point.

This is an instance of the "choices are bad" idea; if we remove the
option to screw up configuring stuff that is a good thing.

We could, instead of failing, just hardwire the switches on and warn.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Martin v. Loewis]

Mark Mitchell <mark@codesourcery.com> writes:

> I agree.  I don't think we need to do this for GCC 3.2, but I do think
> it would be good to do this at some point.

If you don't do this for 3.2, you will definitely end up with two
incompatible ABIs on Linux, both of them in wide use.

Regards,
Martin

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

--On Monday, August 05, 2002 10:16:35 PM +0200 "Martin v. Loewis" 
<martin@v.loewis.de> wrote:

> Mark Mitchell <mark@codesourcery.com> writes:
>
>> I agree.  I don't think we need to do this for GCC 3.2, but I do think
>> it would be good to do this at some point.
>
> If you don't do this for 3.2, you will definitely end up with two
> incompatible ABIs on Linux, both of them in wide use.

Walk me through it, if you please.

How will this happen?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 01:43:26PM -0700, Mark Mitchell wrote:
> --On Monday, August 05, 2002 10:16:35 PM +0200 "Martin v. Loewis" 
> <martin@v.loewis.de> wrote:
> 
> > Mark Mitchell <mark@codesourcery.com> writes:
> >
> >> I agree.  I don't think we need to do this for GCC 3.2, but I do think
> >> it would be good to do this at some point.
> >
> > If you don't do this for 3.2, you will definitely end up with two
> > incompatible ABIs on Linux, both of them in wide use.
> 
> Walk me through it, if you please.
> 
> How will this happen?

If one gcc is configured with --enable-threads=posix and one without this,
then the 2 aren't ABI compatible (see the list of libstdc++-v3
make check failures I got when doing this and swapping the 2 libraries).

If one gcc is configured on glibc 2.2.5+ and one on old glibc, then the
former can run everybody's applications/libraries while the latter only
apps/libraries compiled using that compiler.

	Jakub

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

--On Monday, August 05, 2002 04:48:31 PM -0400 Jakub Jelinek 
<jakub@redhat.com> wrote:

> On Mon, Aug 05, 2002 at 01:43:26PM -0700, Mark Mitchell wrote:
>> --On Monday, August 05, 2002 10:16:35 PM +0200 "Martin v. Loewis"
>> <martin@v.loewis.de> wrote:
>>
>> > Mark Mitchell <mark@codesourcery.com> writes:
>> >
>> >> I agree.  I don't think we need to do this for GCC 3.2, but I do think
>> >> it would be good to do this at some point.
>> >
>> > If you don't do this for 3.2, you will definitely end up with two
>> > incompatible ABIs on Linux, both of them in wide use.
>>
>> Walk me through it, if you please.
>>
>> How will this happen?
>
> If one gcc is configured with --enable-threads=posix and one without this,
> then the 2 aren't ABI compatible (see the list of libstdc++-v3
> make check failures I got when doing this and swapping the 2 libraries).
>
> If one gcc is configured on glibc 2.2.5+ and one on old glibc, then the
> former can run everybody's applications/libraries while the latter only
> apps/libraries compiled using that compiler.

OK; I understand the technical issue.  I should have been more clear;
how will the "both of them in wide use" part happen?

The whole point of 3.2 is for all the distributors to have a chance to
get to a common ABI.  I'd assume they will be able to get together and
agree on the right set of configure options.  I have no objection to
automating that more -- in fact I'd like it if we did -- but I don't
see this as a showstopper.  (At least not yet.)

People building their own GCC -- rather than getting stuff from a
GNU/Linux distributor -- are going to have a harder time.  But, they're
doing things the hard way; I don't mind that.

*If* things are configured correctly, do the problems Benjamin mentioned
go away?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Martin v. Loewis]

Mark Mitchell <mark@codesourcery.com> writes:

> OK; I understand the technical issue.  I should have been more clear;
> how will the "both of them in wide use" part happen?
> 
> The whole point of 3.2 is for all the distributors to have a chance to
> get to a common ABI.  I'd assume they will be able to get together and
> agree on the right set of configure options.  

They certainly will. However, Linux users will build their own gcc 3
installations for existing Linux installations. Those won't be
compatible with what the distributors include in their next
distributions. I believe that there will be many such installations.

> People building their own GCC -- rather than getting stuff from a
> GNU/Linux distributor -- are going to have a harder time.  But, they're
> doing things the hard way; I don't mind that.

My concern is that they don't get an error indication except for the
crash, and it will be often very difficult to analyse what kind of
libgcc_s was in use.

This is especially unfortunate since the problem can be fixed in gcc:
- gcc could make those two ABIs compatible (by deciding at run-time
  whether to invoke __register_frame_info_bases), or
- gcc could you symbol versioning, to make the two versions of libgcc_s
  distinguishable, or
- gcc could refuse to build itself unless that is overridden by the
  user.

Regards,
Martin

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Andreas Jaeger]

Mark Mitchell <mark@codesourcery.com> writes:

> The whole point of 3.2 is for all the distributors to have a chance to
> get to a common ABI.  I'd assume they will be able to get together and
> agree on the right set of configure options.  I have no objection to
> automating that more -- in fact I'd like it if we did -- but I don't
> see this as a showstopper.  (At least not yet.)

Can we put up some webpage that defines this common ABI and what
versions of tools (binutils,glibc) and what configure flags need to
get used?  That way it is documented and we can point people to it,

I do think we agree on the configure options in general but let's
check whild working on that page...

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

--On Tuesday, August 06, 2002 07:00:42 AM +0200 Andreas Jaeger <aj@suse.de> 
wrote:

Mark Mitchell <mark@codesourcery.com> writes:

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Gerald Pfeifer]

On Mon, 5 Aug 2002, Jakub Jelinek wrote:
> What's so hard on upgrading glibc?

It requires root access.

On Mon, 5 Aug 2002, Mark Mitchell wrote:
> People building their own GCC -- rather than getting stuff from a
> GNU/Linux distributor -- are going to have a harder time.  But, they're
> doing things the hard way; I don't mind that.

I do.

Both of you are making assumptions which simply are not correct. Just
consider students working on theses in some student lab or network at
a university: There, you neither have root access, nor are you necessarily
an experienced GCC developer/user, but still you might need to install
an up-to-date version of GCC in your home directory for your work.

Been there, done that (and became a GCC regular because of that).

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

Both of you are making assumptions which simply are not correct. Just
consider students working on theses in some student lab or network at
a university: There, you neither have root access, nor are you necessarily
an experienced GCC developer/user, but still you might need to install
an up-to-date version of GCC in your home directory for your work.

Been there, done that (and became a GCC regular because of that).

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Martin v. Loewis]

Mark Mitchell <mark@codesourcery.com> writes:

> >> I agree.  I don't think we need to do this for GCC 3.2, but I do think
> >> it would be good to do this at some point.
> >
> > If you don't do this for 3.2, you will definitely end up with two
> > incompatible ABIs on Linux, both of them in wide use.
> 
> Walk me through it, if you please.
> 
> How will this happen?

The elaborate walkthrough is in

http://gcc.gnu.org/ml/gcc/2002-08/msg00192.html

Here is the short version: Linuxes fall in two categories:

- those that have glibc 2.2.5 or better, and binutils 2.12.1 or better
  (type A)
- those that miss either the latest binutils, or the latest glibc
  (type B)

Type A systems use unwind-dw2-fde-glibc in libgcc_s, and do not invoke
__register_frame_info_bases in crtstuff. Type B systems use unwind-dw2-fde,
and do invoke __register_frame_info_bases.

If a program or DSO that catches an exception is compiled on a type A
system, this program will std::terminate on a type B system, since
_Unwind_Find_FDE will fail to find the frame info. 

So, binaries compiled on type A systems have an ABI not supported on
type B systems. Compatibility in the other direction is supported.

Unfortunately, all Linux distributions shipped today are type B
systems (with the exception of Debian 3.0). So anybody building gcc
3.2 on a current Linux system will get a type B ABI.

All future releases of Linux will be type A systems, as they surely
use latest binutils and glibc (unless a vendor isn't aware of the
issues, and fails to use the latest stuff with gcc 3.2).

Users of type B systems will find that binaries abort that work fine
on other systems, with no indication of an error.

Does this make the problem clear?

Regards,
Martin

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

> So, binaries compiled on type A systems have an ABI not supported on
> type B systems. Compatibility in the other direction is supported.
>
> Unfortunately, all Linux distributions shipped today are type B
> systems (with the exception of Debian 3.0). So anybody building gcc
> 3.2 on a current Linux system will get a type B ABI.
>
> All future releases of Linux will be type A systems, as they surely
> use latest binutils and glibc (unless a vendor isn't aware of the
> issues, and fails to use the latest stuff with gcc 3.2).
>
> Users of type B systems will find that binaries abort that work fine
> on other systems, with no indication of an error.
>
> Does this make the problem clear?

Yes.  It was, in fact, I who was unclear: I was looking for a
justification of your claim that this would be a problem. :-)

I understand the technical issue.  However, my thinking is that
people who care about building ABI compliant software will
generally not be doing it on current systems using home-built
compilers; they'll probably get either new systems or new compilers
from distributors.  And I would assume that the distributors will
build the new compilers correctly, even if building packages for
existing systems.

That said, I'll reiterate: if someone wants to tweak configure, fine.

Do it quickly, send me a patch, and we can obviate the debate by having
the change in.  I just can't see holding up the release for that.

I still need to know, though, whether Benjamin's problems have been
solved or not, and what we're doing about Franz's versioning suggestion.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Franz Sirl]

On Montag, 5. August 2002 23:58, Mark Mitchell wrote:
> I still need to know, though, whether Benjamin's problems have been
> solved or not, and what we're doing about Franz's versioning suggestion.

I'm waiting for a final word from Jakub, but I'm still convinced it's the 
right way to go. gcc-3.2 will be the first widely deployed compiler on 
powerpc-linux-gnu since gcc-2.95 and I would like to cast a really correct 
ABI in stone rather than a "it works so far and is mostly correct" ABI.

Franz.

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

--On Tuesday, August 06, 2002 12:12:19 AM +0200 Franz Sirl 
<Franz.Sirl-kernel@lauterbach.com> wrote:

> On Montag, 5. August 2002 23:58, Mark Mitchell wrote:
>> I still need to know, though, whether Benjamin's problems have been
>> solved or not, and what we're doing about Franz's versioning suggestion.
>
> I'm waiting for a final word from Jakub, but I'm still convinced it's the
> right way to go. gcc-3.2 will be the first widely deployed compiler on
> powerpc-linux-gnu since gcc-2.95 and I would like to cast a really
> correct  ABI in stone rather than a "it works so far and is mostly
> correct" ABI.

My reading of Jakub's messages is that he thinks what you want to do is
OK -- but not necessary.  If there's no downside, I'd prefer to trust
your judgement.  Jakub, why not do what Franz suggests?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 02:58:40PM -0700, Mark Mitchell wrote:
> I still need to know, though, whether Benjamin's problems have been
> solved or not

I cannot reproduce it.
I have made both plain ../configure i386-redhat-linux
builds (gcc-3_2-branch, HEAD) and
../configure i386-redhat-linux --enable-threads-posix --enable-shared --enable-__cxa_atexit
bootstraps, libstdc++ in all 4 cases showed one FAIL and a bunch of XPASSes.
That was repeated after I exchanged libstdc++.so.5.0.0 binaries between
the trees.
So to me both libstdc++.so.5 look compatible (and likewise C++, at least
to the extent covered by consistency.vlad (minus some __alignof__ of
non-fields)).

Both were vanilla checkouts (the former from the weekend, the pthread builds
Monday vintage).

> , and what we're doing about Franz's versioning suggestion.

As I already wrote, I don't think this is necessary, especially this late
in the game, but if Richard or Geoff think otherwise...

BTW: What about the IA-32 bitfield ABI bug and what about __m64 alignment?

	Jakub

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Richard Henderson]

On Mon, Aug 05, 2002 at 06:29:22PM -0400, Jakub Jelinek wrote:
> > , and what we're doing about Franz's versioning suggestion.
> 
> As I already wrote, I don't think this is necessary, especially this late
> in the game, but if Richard or Geoff think otherwise...

My mail has been screwed up all weekend.  What's the issue here?

> BTW: What about the IA-32 bitfield ABI bug and what about __m64 alignment?

Is the bitfield thing the alignment of long long bit fields?
I seem to recall seeing something about C++ changing, but that
it now matched C.  Did someone check and see that C changed at
some point in the 3.x series?

As for __m64, IIRC this is fixed on mainline.  We should indeed
backport this for 3.2.  Thanks for the reminder.


r~

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 04:48:14PM -0700, Richard Henderson wrote:
> On Mon, Aug 05, 2002 at 06:29:22PM -0400, Jakub Jelinek wrote:
> > > , and what we're doing about Franz's versioning suggestion.
> > 
> > As I already wrote, I don't think this is necessary, especially this late
> > in the game, but if Richard or Geoff think otherwise...
> 
> My mail has been screwed up all weekend.  What's the issue here?

Franz wants to export a bunch of libgcc_s symbols at @@GCC_3.0 and
@GLIBC_2.0 instead of current @@GLIBC_2.0.
See http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00252.html

> > BTW: What about the IA-32 bitfield ABI bug and what about __m64 alignment?
> 
> Is the bitfield thing the alignment of long long bit fields?

No, the bitfield is alignment of things like int foo : 128; etc.
This changed when Jan removed BIGGEST_FIELD_ALIGNMENT,
as in this case the type is SImode and the proposed alignment is 64
and BIGGEST_FIELD_ALIGNMENT was giving 32 while in x86_field_alignment
this only happens for {DI,DC,DCI,DF}mode and not SImode as needed in
this case. There are a couple of tests for this in Intel ABI testsuite
and it is a regression from 3.1.
See http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00293.html.

> I seem to recall seeing something about C++ changing, but that
> it now matched C.  Did someone check and see that C changed at
> some point in the 3.x series?

C doesn't allow oversized bitfields, for say int it treats them as
int foo : 32 when they are bigger (at least gcc, haven't checked
the standards on this).

> As for __m64, IIRC this is fixed on mainline.  We should indeed
> backport this for 3.2.  Thanks for the reminder.

Maybe I misunderstood the thread about SSE types in June, but
I understood this should succeed, shouldn't it:

#include <mmintrin.h>

struct A
{
  char a;
  __m64 b;
  char c;
} x;

int foo ()
{
  if ((char *) &x.b - &x.a != 8)
    abort ();
  if (&x.c - (char *) &x.b != 8)
    abort ();
  if (sizeof (x) != 24)
    abort ();
}

(unlike long long instead of __m64).
This fails on mainline too.

	Jakub

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Neil Booth]

Jakub Jelinek wrote:-

> C doesn't allow oversized bitfields, for say int it treats them as
> int foo : 32 when they are bigger (at least gcc, haven't checked
> the standards on this).

It's a constraint violation in C99.

Neil.

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Richard Henderson]

On Tue, Aug 06, 2002 at 02:36:35AM -0400, Jakub Jelinek wrote:
> See http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00252.html

Franz, I still don't see why the divide routines can't
stay in the GLIBC_2.0 version.  You say you saw "this"
in "the wild", but don't actually describe the failure
mode.

I don't like the patch much either.  I'm sure it would be
better to do it from the source level inside libgcc2.c.
Though it would still be a hack.

> See http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00293.html.

Jakub, this patch looks right.

> Maybe I misunderstood the thread about SSE types in June, but
> I understood this should succeed, shouldn't it:

Yes.

> This fails on mainline too.

Hum.  The patch I remember doesn't seem to have been written. :-(
As discussed on the thread, __m64 needs to be a vector type so 
that the x86-64 calling conventions put it in the right set of
registers.  Which means a large repetitious patch to mmintrin.h.


r~

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

See http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00293.html .

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Jakub Jelinek]

On Tue, Aug 06, 2002 at 09:14:33AM -0700, Mark Mitchell wrote:
> No, there is something wrong with that patch.
> 
> In particular, the test case wants this structure:
> 
> +struct A
> +{
> +  char a;
> +  int b : 224;	// { dg-warning "exceeds its type" "" }
> +  char c;
> +} a, a4[4];
> +
> 
> to have size 36.  That is incorrect.
> 
>   int b: 224;
> 
> should be treated exactly like:
> 
>   long long: 64;
> 
> followed by 160 bits (20 bytes) of padding.
> 
> In the C ABI, a 64-bit long long bit field gets aligned at an 8-byte
> boundary.  So, b goes at offset 8.  We then get 28 bytes for the
> bitfield.  That puts c at offset 36.  The structure is 8-byte aligned,
> for a total size of 40.
> 
> Jakub, what is the bug that you are trying to fix?
> 
> The fact that something changed in 3.1 doesn't prove that it's a bug. :-)

The change for bitfields in 3.1.1 was definitely not intentional (Jan's patch
was about SSE field alignment and TFmode long doubles) and Intel compiler
behaves the same way as gcc always used to.

I looked into C++ standard and couldn't find anything about
int :64; needing exactly the same treatment as long long :64.

> > Hum.  The patch I remember doesn't seem to have been written. :-(
> > As discussed on the thread, __m64 needs to be a vector type so
> > that the x86-64 calling conventions put it in the right set of
> > registers.  Which means a large repetitious patch to mmintrin.h.
> 
> Well, I'm not too concerned about x86-64 just yet.  There still isn't
> any hardware out there.  I can't see holding the release for this.

Not x86-64, but it makes a difference on i686 too (ie. whether __m64
fields in structures are 64-bit or just 32-bit aligned).

	Jakub

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Jakub Jelinek]

On Tue, Aug 06, 2002 at 10:03:54AM -0700, Mark Mitchell wrote:
> 
> > I looked into C++ standard and couldn't find anything about
> > int :64; needing exactly the same treatment as long long :64.
> 
> See:
> 
>   http://www.codesourcery.com/cxx-abi/abi.html#class-types
> 
> In particular, 2.4.II.1.b.

That doesn't make it any more clear than it used to, though
my understanding of this is that gcc 3.0-3.1 were correct in here:

If sizeof(T)*8 < n, let T' be the largest integral POD type with
sizeof(T')*8 <= n. The bitfield is allocated starting at the next
offset aligned appropriately for T', with length n bits. The first
sizeof(T)*8 bits are used to hold the value of the bitfield,
followed by n - sizeof(T)*8 bits of padding.

T' is long long (what happens when __int128_t type is added btw: will
bitfield alignment suddently change?), so the above text requires the
bitfield to be allocated starting at the next offset aligned appropriately
for long long (which is 32-bit alignment), with length 64 bits.

(If the text said at the next offset aligned appropriately for bitfield
with base type T' or something like that, it would be different).

The fact that long long foo : 64 bitfields are aligned to 64 bits comes from
the 2.4.II.1.a requirement to match C psABI for bitfields.

> >> > Hum.  The patch I remember doesn't seem to have been written. :-(
> >> > As discussed on the thread, __m64 needs to be a vector type so
> >> > that the x86-64 calling conventions put it in the right set of
> >> > registers.  Which means a large repetitious patch to mmintrin.h.
> >>
> >> Well, I'm not too concerned about x86-64 just yet.  There still isn't
> >> any hardware out there.  I can't see holding the release for this.
> >
> > Not x86-64, but it makes a difference on i686 too (ie. whether __m64
> > fields in structures are 64-bit or just 32-bit aligned).
> 
> This is a C ABI issue in addition to being a C++ ABI issue.
> 
> At some point, we'll break the C ABI to fix this, and with it the C++
> ABI -- for programs that use this extended type.
> 
> The bottom line is that we don't have a patch.  Unless someone is going
> to make one PDQ, what are we going to do?

Well, for IA-32 the fix should be trivial (see bellow). x86-64 will have
to wait for 3.3.

2002-08-06  Jakub Jelinek  <jakub@redhat.com>

	* config/i386/mmintrin.h (__m64): Make the type 64-bit aligned.

--- gcc/config/i386/mmintrin.h.jj	2002-01-12 08:38:49.000000000 +0100
+++ gcc/config/i386/mmintrin.h	2002-08-06 20:05:02.000000000 +0200
@@ -31,7 +31,7 @@
 #define _MMINTRIN_H_INCLUDED
 
 /* The data type intended for user use.  */
-typedef unsigned long long __m64;
+typedef unsigned long long __m64 __attribute__ ((__aligned__ (8)));
 
 /* Internal data types for implementing the intrinsics.  */
 typedef int __v2si __attribute__ ((__mode__ (__V2SI__)));


	Jakub

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

If sizeof(T)*8 < n, let T' be the largest integral POD type with
sizeof(T')*8 <= n. The bitfield is allocated starting at the next
offset aligned appropriately for T', with length n bits. The first
sizeof(T)*8 bits are used to hold the value of the bitfield,
followed by n - sizeof(T)*8 bits of padding.

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Richard Henderson]

On Tue, Aug 06, 2002 at 11:18:49AM -0700, Mark Mitchell wrote:
> The real oddity here is that "long long : 64" is aligned more strictly
> than "long long" by the C compiler.

By *which* C compiler?  Yes, gcc 3.2 aligns a long long bitfield
to 64-bit, but egcs 2.91 certainly does not.

	struct s
	{
	  int a;
	  long long : 64;
	  int b;
	};

	main()
	{
	  struct s s;
	  printf("%ld\n", &s.b - &s.a);
	  return 0;
	}

Yields:

	egcs 1.1.2	3
	gcc 2.95.3	3
	gcc 2.96-108	4
	gcc 3.0.3	4
	gcc 3.2		4

So what do we do?  Personally I'm for fixing the bug.


r~

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

--On Tuesday, August 06, 2002 01:17:04 PM -0700 Richard Henderson 
<rth@redhat.com> wrote:

On Tue, Aug 06, 2002 at 11:18:49AM -0700, Mark Mitchell wrote:

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Geoff Keating]

Mark Mitchell <mark@codesourcery.com> writes:

> Blech.  I don't like that we broke the C ABI, but I'm not sure I like
> breaking it again in the name of fixing it, some two years later.
> 
> I guess the fact that nobody noticed until now suggests that maybe
> the problem isn't very common, which makes either decision less
> important.

This is perhaps why my testing builds occasionally fail when I start
by bootstrapping in a directory and then just do 'cd gcc ; make' after
changing something.  I knew it was a structure layout problem, because
one symptom was that warnings are treated as errors because GCC looks
at the wrong word in the structure when examining the error count.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Michael Matz]

Hi,

On Tue, 6 Aug 2002, Mark Mitchell wrote:

> > So what do we do?  Personally I'm for fixing the bug.
>
> Blech.  I don't like that we broke the C ABI, but I'm not sure I like
> breaking it again in the name of fixing it, some two years later.

Well, it was only broken in one released version of gcc, which isn't in
wide use yet (3.0.x).  Redhat's 2.96 has it also, but ...

> I guess the fact that nobody noticed until now suggests that maybe
> the problem isn't very common, which makes either decision less
> important.

The more it should be fixed, then.  Unless we want to cast that breakage
in stone.


Ciao,
Michael.

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Mark Mitchell]

> As I already wrote, I don't think this is necessary, especially this late
> in the game, but if Richard or Geoff think otherwise...

OK, we'll see what they say.

> BTW: What about the IA-32 bitfield ABI bug and what about __m64 alignment?

Would you mind summarizing the details for these two as well?

I am keeping notes on all of these issues, but I'd like a concise summary.

Thanks!

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

[PATCH] Default to --enable-threads=posix on Linux (was Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils)

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 02:58:40PM -0700, Mark Mitchell wrote:
> Do it quickly, send me a patch, and we can obviate the debate by having
> the change in.  I just can't see holding up the release for that.

Here is the proposed minimum patch to default to --enable-threads=posix
unless either some other --enable-threads option or --disable-threads
is given on Linux. I don't see why somebody might want not to build thread
aware gcc/libstdc++ by default.

I've verified that configure with --disable-threads gives the configuration
which used to be, ie. no thread support and that no --*threads option given
to configure causes posix threads to be used.

Ok to commit to mainline/3.2 branch?

2002-08-06  Jakub Jelinek  <jakub@redhat.com>

	* config.gcc (alpha*-*-linux*, hppa*-*-linux*, i[34567]86-*-linux*,
	x86_64-*-linux*, ia64*-*-linux*, m68k-*-linux*, mips*-*-linux*,
	powerpc-*-linux-gnualtivec*, powerpc-*-linux*, s390-*-linux*,
	s390x-*-linux*, sh-*-linux*, sparc-*-linux*, sparc64-*-linux*): Default
	to --enable-threads=posix if no --{enable,disable}-threads is given
	to configure.

--- gcc/config.gcc.jj	2002-06-10 23:25:16.000000000 +0200
+++ gcc/config.gcc	2002-08-06 11:35:53.000000000 +0200
@@ -558,9 +558,10 @@ alpha*-*-linux*)
 	tmake_file="t-slibgcc-elf-ver t-linux alpha/t-crtfm alpha/t-alpha alpha/t-ieee"
 	extra_parts="crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o"
 	gas=yes gnu_ld=yes
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	;;
 alpha*-*-freebsd*)
 	tm_file="${tm_file} ${fbsd_tm_file} alpha/elf.h alpha/freebsd.h"
@@ -871,9 +872,10 @@ hppa*-*-linux* | parisc*-*-linux*)
 	tmake_file="t-slibgcc-elf-ver t-linux pa/t-linux"
 	extra_parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o"
 	gas=yes gnu_ld=yes
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	;;
 hppa*-*-openbsd*)
 	target_cpu_default="MASK_PA_11"
@@ -1316,9 +1318,10 @@ i[34567]86-*-linux*)	# Intel 80386's run
 	extra_parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o"
 	gnu_ld=yes
 	float_format=i386
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	;;
 x86_64-*-linux*)
 	tm_file="${tm_file} i386/att.h dbxelf.h elfos.h svr4.h linux.h \
@@ -1327,9 +1330,10 @@ x86_64-*-linux*)
 	extra_parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o"
 	gnu_ld=yes
 	float_format=i386
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	;;
 i[34567]86-*-gnu*)
 	float_format=i386
@@ -1705,9 +1709,10 @@ ia64*-*-linux*)
 	tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h ia64/sysv4.h ia64/linux.h"
 	tmake_file="t-slibgcc-elf-ver t-linux ia64/t-ia64 ia64/t-glibc"
 	target_cpu_default="MASK_GNU_AS|MASK_GNU_LD"
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	float_format=i386
 	;;
 ia64*-*-hpux*)
@@ -2098,9 +2103,10 @@ m68k-*-linux*)		# Motorola m68k's runnin
 	extra_parts="crtbegin.o crtbeginS.o crtend.o crtendS.o"
 	float_format=m68k
 	gnu_ld=yes
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	;;
 m68k-*-psos*)
 	tmake_file=m68k/t-m68kbare
@@ -2397,9 +2403,10 @@ mips*-*-linux*)				# Linux MIPS, either 
 	extra_parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o"
 	gnu_ld=yes
 	gas=yes
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	;;
 mips*el-*-openbsd*)	# mips little endian
 	target_cpu_default="MASK_GAS|MASK_ABICALLS"
@@ -2867,17 +2874,19 @@ powerpc-*-linux-gnualtivec*)
 	tm_file="${tm_file} dbxelf.h elfos.h svr4.h freebsd-spec.h rs6000/sysv4.h rs6000/linux.h rs6000/linuxaltivec.h"
 	out_file=rs6000/rs6000.c
 	tmake_file="rs6000/t-ppcos t-slibgcc-elf-ver t-linux rs6000/t-ppccomm"
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	;;
 powerpc-*-linux*)
 	tm_file="${tm_file} dbxelf.h elfos.h svr4.h freebsd-spec.h rs6000/sysv4.h rs6000/linux.h"
 	out_file=rs6000/rs6000.c
 	tmake_file="rs6000/t-ppcos t-slibgcc-elf-ver t-linux rs6000/t-ppccomm"
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	;;
 powerpc-*-gnu-gnualtivec*)
 	tm_file="${cpu_type}/${cpu_type}.h elfos.h svr4.h freebsd-spec.h gnu.h rs6000/sysv4.h rs6000/linux.h rs6000/linuxaltivec.h rs6000/gnu.h"
@@ -2993,9 +3002,10 @@ s390-*-linux*)
 	tm_file="s390/s390.h dbxelf.h elfos.h svr4.h linux.h s390/linux.h"
 	tmake_file="t-slibgcc-elf-ver t-linux s390/t-linux"
 	extra_parts="crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o"
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	;;
 s390x-*-linux*)
 	tm_file="s390/s390x.h s390/s390.h dbxelf.h elfos.h svr4.h linux.h s390/linux.h"
@@ -3004,9 +3014,10 @@ s390x-*-linux*)
 	out_file=s390/s390.c
 	tmake_file="t-slibgcc-elf-ver t-linux s390/t-linux s390/t-linux64"
 	extra_parts="crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o"
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	;;
 sh-*-elf*)
 	tmake_file="sh/t-sh sh/t-elf"
@@ -3045,9 +3056,10 @@ sh-*-linux*)
 	tm_file="${tm_file} sh/elf.h sh/linux.h"
 	tmake_file="sh/t-sh sh/t-elf sh/t-linux"
 	gas=yes gnu_ld=yes
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	float_format=sh
 	;;
 sh-*-*)
@@ -3131,9 +3143,10 @@ sparc-*-linux*)		# Sparc's running GNU/L
 	tmake_file="t-slibgcc-elf-ver t-linux sparc/t-crtfm"
 	extra_parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o"
 	gnu_ld=yes
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	float_format=sparc
 	;;
 sparc-*-lynxos*)
@@ -3332,9 +3345,10 @@ sparc64-*-linux*)		# 64-bit Sparc's runn
 	tm_file="sparc/biarch64.h ${tm_file} dbxelf.h elfos.h svr4.h sparc/sysv4.h sparc/linux64.h"
 	extra_parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o"
 	gnu_ld=yes
-	if test x$enable_threads = xyes; then
-		thread_file='posix'
-	fi
+	case x${enable_threads} in
+		x | xyes) thread_file='posix'
+		;;
+	esac
 	float_format=sparc
 	;;
 sparc64-*-netbsd*)


	Jakub

Re: [PATCH] Default to --enable-threads=posix on Linux (was Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils)

[Christoph Hellwig]

On Tue, Aug 06, 2002 at 11:31:55AM +0200, Jakub Jelinek wrote:
> 2002-08-06  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* config.gcc (alpha*-*-linux*, hppa*-*-linux*, i[34567]86-*-linux*,
> 	x86_64-*-linux*, ia64*-*-linux*, m68k-*-linux*, mips*-*-linux*,
> 	powerpc-*-linux-gnualtivec*, powerpc-*-linux*, s390-*-linux*,
> 	s390x-*-linux*, sh-*-linux*, sparc-*-linux*, sparc64-*-linux*): Default
> 	to --enable-threads=posix if no --{enable,disable}-threads is given
> 	to configure.

What about doing it once in a common linux block?

Re: [PATCH] Default to --enable-threads=posix on Linux (was Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils)

[Franz Sirl]

At 11:31 06.08.2002, Jakub Jelinek wrote:
>On Mon, Aug 05, 2002 at 02:58:40PM -0700, Mark Mitchell wrote:
> > Do it quickly, send me a patch, and we can obviate the debate by having
> > the change in.  I just can't see holding up the release for that.
>
>Here is the proposed minimum patch to default to --enable-threads=posix
>unless either some other --enable-threads option or --disable-threads
>is given on Linux. I don't see why somebody might want not to build thread
>aware gcc/libstdc++ by default.
>
>I've verified that configure with --disable-threads gives the configuration
>which used to be, ie. no thread support and that no --*threads option given
>to configure causes posix threads to be used.
>
>Ok to commit to mainline/3.2 branch?

Uhm, wouldn't it be easier to put one test under *-*-linux* instead of 
duplicating it all over?

Franz.

Re: [PATCH] Default to --enable-threads=posix on Linux (was Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils)

[Jakub Jelinek]

On Tue, Aug 06, 2002 at 11:54:26AM +0200, Franz Sirl wrote:
> At 11:31 06.08.2002, Jakub Jelinek wrote:
> >On Mon, Aug 05, 2002 at 02:58:40PM -0700, Mark Mitchell wrote:
> > > Do it quickly, send me a patch, and we can obviate the debate by having
> > > the change in.  I just can't see holding up the release for that.
> >
> >Here is the proposed minimum patch to default to --enable-threads=posix
> >unless either some other --enable-threads option or --disable-threads
> >is given on Linux. I don't see why somebody might want not to build thread
> >aware gcc/libstdc++ by default.
> >
> >I've verified that configure with --disable-threads gives the configuration
> >which used to be, ie. no thread support and that no --*threads option given
> >to configure causes posix threads to be used.
> >
> >Ok to commit to mainline/3.2 branch?
> 
> Uhm, wouldn't it be easier to put one test under *-*-linux* instead of 
> duplicating it all over?

Well, *-*-linux* covers all the unwanted variants like
*-*-linux*ecoff*
*-*-linux*libc1*
*-*-linux*oldld*
*-*-linux*aout*

That can be of course solved by one case ... esac. What I'm not sure
is whether ports like xtensa-*-linux* want threading by
default, I don't see any support for them in glibc.

	Jakub

Re: [PATCH] Default to --enable-threads=posix on Linux (was Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils)

[Franz Sirl]

At 12:20 06.08.2002, Jakub Jelinek wrote:
>On Tue, Aug 06, 2002 at 11:54:26AM +0200, Franz Sirl wrote:
> > At 11:31 06.08.2002, Jakub Jelinek wrote:
> > >On Mon, Aug 05, 2002 at 02:58:40PM -0700, Mark Mitchell wrote:
> > > > Do it quickly, send me a patch, and we can obviate the debate by having
> > > > the change in.  I just can't see holding up the release for that.
> > >
> > >Here is the proposed minimum patch to default to --enable-threads=posix
> > >unless either some other --enable-threads option or --disable-threads
> > >is given on Linux. I don't see why somebody might want not to build thread
> > >aware gcc/libstdc++ by default.
> > >
> > >I've verified that configure with --disable-threads gives the 
> configuration
> > >which used to be, ie. no thread support and that no --*threads option 
> given
> > >to configure causes posix threads to be used.
> > >
> > >Ok to commit to mainline/3.2 branch?
> >
> > Uhm, wouldn't it be easier to put one test under *-*-linux* instead of
> > duplicating it all over?
>
>Well, *-*-linux* covers all the unwanted variants like
>*-*-linux*ecoff*
>*-*-linux*libc1*
>*-*-linux*oldld*
>*-*-linux*aout*

These can exit early in a global test by listing them first.

>That can be of course solved by one case ... esac. What I'm not sure
>is whether ports like xtensa-*-linux* want threading by
>default, I don't see any support for them in glibc.

Hmm, but xtensa-*-linux* supports the enable-threads switch..., I guess the 
port hasn't been contributed to glibc yet.

The questionable ones matching are:

hppa*64*-*-linux* | parisc*64*-*-linux*): doesn't handle --enable-threads, 
possibly a bug since 32bit hppa supports it

pj*-linux*): isn't this one already gone in the mainline?

powerpc64-*-linux*): wow, no --enable-threads support here? sounds very 
much like a bug too

We could force thread_file='single' for these if enable_threads is unset, 
this would still result in less code duplication.

But maybe this can wait for the mainline/3.2.1 and we go with your patch 
for 3.2.

Franz.

Re: [PATCH] Default to --enable-threads=posix on Linux (was Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils)

[Daniel Jacobowitz]

On Tue, Aug 06, 2002 at 02:21:26PM +0200, Franz Sirl wrote:
> At 12:20 06.08.2002, Jakub Jelinek wrote:
> >On Tue, Aug 06, 2002 at 11:54:26AM +0200, Franz Sirl wrote:
> >> At 11:31 06.08.2002, Jakub Jelinek wrote:
> >> >On Mon, Aug 05, 2002 at 02:58:40PM -0700, Mark Mitchell wrote:
> >> > > Do it quickly, send me a patch, and we can obviate the debate by 
> >having
> >> > > the change in.  I just can't see holding up the release for that.
> >> >
> >> >Here is the proposed minimum patch to default to --enable-threads=posix
> >> >unless either some other --enable-threads option or --disable-threads
> >> >is given on Linux. I don't see why somebody might want not to build 
> >thread
> >> >aware gcc/libstdc++ by default.
> >> >
> >> >I've verified that configure with --disable-threads gives the 
> >configuration
> >> >which used to be, ie. no thread support and that no --*threads option 
> >given
> >> >to configure causes posix threads to be used.
> >> >
> >> >Ok to commit to mainline/3.2 branch?
> >>
> >> Uhm, wouldn't it be easier to put one test under *-*-linux* instead of
> >> duplicating it all over?
> >
> >Well, *-*-linux* covers all the unwanted variants like
> >*-*-linux*ecoff*
> >*-*-linux*libc1*
> >*-*-linux*oldld*
> >*-*-linux*aout*
> 
> These can exit early in a global test by listing them first.
> 
> >That can be of course solved by one case ... esac. What I'm not sure
> >is whether ports like xtensa-*-linux* want threading by
> >default, I don't see any support for them in glibc.
> 
> Hmm, but xtensa-*-linux* supports the enable-threads switch..., I guess the 
> port hasn't been contributed to glibc yet.

That's right... and it looks like xtensa-*-linux* does have
linuxthreads support.

> But maybe this can wait for the mainline/3.2.1 and we go with your patch 
> for 3.2.

I'd rather move all Linux targets to --enable-threads=posix; I believe
all current glibc ports have threads support, so why not?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] Default to --enable-threads=posix on Linux (was Re:libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils)

[Mark Mitchell]

Re: [PATCH] Default to --enable-threads=posix on Linux (was Re:libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils)

[Mark Mitchell]