[parisc-linux] Re: NPTL pthread_cancel and libgcc_s.so.2 vs. libgcc_s.so.1 (Why the DSO version bump?)

[parisc-linux] Re: NPTL pthread_cancel and libgcc_s.so.2 vs. libgcc_s.so.1 (Why the DSO version bump?)

[John David Anglin]

> What was the reason for DSO version bump in libgcc_s.so.1?

It was done to distinguish between libgcc_s's built with sjlj and dwarf2
eh support, respectively.  They use incompatible unwind routines and it's
not possible to support both exception handling techniques with one library.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: NPTL pthread_cancel and libgcc_s.so.2 vs. libgcc_s.so.1 (Why the DSO version bump?)

[Carlos O'Donell]

On Tue, Aug 02, 2005 at 10:13:42AM -0400, John David Anglin wrote:
> > What was the reason for DSO version bump in libgcc_s.so.1?
> 
> It was done to distinguish between libgcc_s's built with sjlj and dwarf2
> eh support, respectively.  They use incompatible unwind routines and it's
> not possible to support both exception handling techniques with one library.

So libgcc_s.so.1 is for dwarf2?
While libgcc_s.so.2 is for sjlj?

Thus NPTL thread cancellation seems to requires dwarf2 eh support.
How do I enable sjlj versus dwarf2 (--enable-dwarf2-exceptions?)

Our build script is here if you want to have a look:
http://cvs.parisc-linux.org/build-tools/build-tls-tools?rev=1.5&view=markup

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: NPTL pthread_cancel and libgcc_s.so.2 vs. libgcc_s.so.1 (Why the DSO version bump?)

[John David Anglin]

> i386 only has libgcc_s.so.1 and I'm pretty sure that it is compiled with
> dwarf2 support. hppa only has libgcc_s.so.1 and it is sjlj for sure.
> 
> So we have an inconsistent numbering problem?

Yup, but it was unavoidable.  Look on the positive side, i386 doesn't
support sjlj ;)

> The code on hppa should try to load "libgcc_s.so.2" then?

Yes.

> > > Thus NPTL thread cancellation seems to requires dwarf2 eh support.
> > > How do I enable sjlj versus dwarf2 (--enable-dwarf2-exceptions?)
> > 
> > dwarf2 is the default.  --enable-sjlj-exceptions=yes enables sjlj.
> > Debian gcc-3.3 uses sjlj.  Debian gcc-3.4 and later use dwarf2.
> 
> Okay, perfect.

Basic TLS support in GCC is currently in the CVS head and will be
part of gcc-4.1 when it is released.  As long as you don't configure
it with --enable-sjlj-exceptions=yes you will get "libgcc_s.so.2".

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: NPTL pthread_cancel and libgcc_s.so.2 vs. libgcc_s.so.1 (Why the DSO version bump?)

[Carlos O'Donell]

On Wed, Aug 03, 2005 at 01:02:40AM -0400, John David Anglin wrote:
> > i386 only has libgcc_s.so.1 and I'm pretty sure that it is compiled with
> > dwarf2 support. hppa only has libgcc_s.so.1 and it is sjlj for sure.
> > 
> > So we have an inconsistent numbering problem?
> 
> Yup, but it was unavoidable.  Look on the positive side, i386 doesn't
> support sjlj ;)

Haha! :)
 
> > The code on hppa should try to load "libgcc_s.so.2" then?
> 
> Yes.

Perfect. I added some macros to glibc and this worked. It loaded
libgcc_s.so.2 perfectly and the cancellation seems to work. If only I
could fix the other segfault bugs.

> > > > Thus NPTL thread cancellation seems to requires dwarf2 eh support.
> > > > How do I enable sjlj versus dwarf2 (--enable-dwarf2-exceptions?)
> > > 
> > > dwarf2 is the default.  --enable-sjlj-exceptions=yes enables sjlj.
> > > Debian gcc-3.3 uses sjlj.  Debian gcc-3.4 and later use dwarf2.
> > 
> > Okay, perfect.
> 
> Basic TLS support in GCC is currently in the CVS head and will be
> part of gcc-4.1 when it is released.  As long as you don't configure
> it with --enable-sjlj-exceptions=yes you will get "libgcc_s.so.2".

Yes, this is what I was seeing. For the TLS toolchain we are using
dwarf2.

Thanks for the help.

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux