Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib

[IainS <developer at sandoe-acoustics dot co dot uk>]

Gents,
thanks for taking the time to explain stuff - hopefully, in the end,  
we'll resolve this.

---

Firstly, issues with my choice of configure options might be  
important - but they are not relevant to the underlying problem.
	The basic problem is entirely repeatable with default options  
("regress", for example, shows 128 unsupported libgomp tests).

I am happy to be 'blown out of the water' here - but I do want to  
understand the limitations.

If gcc X.Y can deliver greater functionality than the default install  
on darwinX then, IMO, I should be able to pass this onto my clients  
and users.
Obviously, I want to do this in a secure manner, that does not break  
the system for my clients, and is understandable by developers.
[* I am not trying to replicate your work Jack, but seeking a  
different deployment solution - which is required in some cases].

We have strayed, to some extent, from the specific issue of TLS into  
more general areas;  but these are v. important areas (and one might  
at least see this list as partial documentation for some future  
engineer also trying to understand).

===

apropos  emutls (I emailed Jakub, who kindly replied)

1/ The reason that emutls is in gcc_eh is because there must be only  
one copy in an executable.

So, in the general case, when using emults, one must:
(a) link all parts of the executable using emutls statically  (which  
is tedious to achieve on darwin without moving all the dylibs to one  
side)
(b) link with the libgcc_s.1that contains emutls.

so, AFAICT (at least on darwin) these are broken w.r.t emutls:
	gcc main-progam.c -lgcc_eh -lsome-library-already-linked-to-emutls- 
in-gcc_s.1 .....
	gcc main-progam.c -lstatic-libgcc -lsome-library-already-linked-to- 
emutls-in-gcc_s.1 .....
	(in fact, D8 ld won't let you do the second unless "some-library- 
already-linked-to-emutls-in-gcc_s.1" is already installed).

I have a hunch that this is, at least partially, the origin of  
sporadic failures in crayptr2 (which has been one of the very few  
tests using tls so far - because all the rest have been UNSUPPORTED  
by the fails in dg target supports).

2/  If I understand correctly, one must link with the ex. handlers in  
libSystem if one wants proper operation languages using exceptions  
(i.e. the reason that --shared-libgcc is used in the testsuite).  **  
see also below.

So, my kludge to libgomp.exp  "-lgcc_s.1" is probably broken with  
respect to ex. handlers for g++, objc etc.

- unless it's acceptable for a single executable to get its EH code  
from a newer libgcc_s.1
(i.e. is it a matter of consistency, or *must* the EH code absolutely  
come from libSystem, for some other reason ?)

If the static libs are segregated because of these needs - then why  
not segregate the dylibs?
I.E. put the EH code in libgcc_eh.so (which can then be ignored on  
darwin)

====
apropos the general issue of supplying an enhanced gcc runtime set  
onto darwinX
(assuming that the problems are fundamentally resolvable).

On 11 Dec 2008, at 00:13, Geoff Keating wrote:
> On Dec 10, 2008, at 3:24 PM, IainS wrote:
> > On 10 Dec 2008, at 22:36, Geoff Keating wrote:
> > > On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote:
> > > > On Wed, Dec 10, 2008 at 02:55:11PM +0000, IainS wrote:
> >
> > <snip>
> >
> > > To use the 'unversioned set' implies that you're compiling for a  
> > > version of Mac OS that Apple has not yet created and most likely  
> > > will never exist.  This is not useful.
> > >
> > > One way to get extra runtime support is put routines in libgcc.a  
> > > which can be statically linked into executables if they aren't  
> > > present in the system.
> >
> > if one did -lgcc_s.10.x -lgcc_s.1   would that break it?
> > ... should it not pick up only the unresolved symbols from s.1
> >
> > ( you would also have to be  prepared to install libgcc_s.1 in a  
> > suitable place).
>
> The second part here is the tricky part.  I would not recommend  
> installing your libgcc_s.1.dylib in /usr/lib, or anywhere else  
> really, since you don't know that it'll be compatible with the  
> system one.

(a)
--enable-version-specific-runtime-libs**
should ensure that this is achieved without any risk of trampling on  
the system (we certainly do not want to take responsibility for that).
(and with --program-suffix=-x.y.z allows me to have 4.3 and 4.4  
installed along with apple-released 4.0 and 4.2 ... )
 ** providing one does *not* use --with-slibdir=/usr/lib (see below)

(b)
an alternative (especially attractive to me) is:

package a set of gccx.y libs with rpaths @executable_path/../lib

I can then deliver this as a user drag-installable app (perhaps  
wasteful of disk space, but nicely self-contained) :

MyAppUsingGFortran.app
	Contents/
		MacOS/
			MyAppUsingGFortran
		lib/
			libgfortran.dylib
			etc.
			libgcc_s.1.dylib

(c) There are all the other usual suspects ; put the libs in  
DYLD_FALLBACK_LIBRARY_PATH etc. etc.

> > > The routines in libgcc_eh.a are routines which should normally  
> > > never be statically linked into executables, because they won't  
> > > work if you do that; they must be in the system.  If you need a  
> > > routine that's in libgcc_eh.a, and it's not in the system, you're  
> > > out of luck; you can't use it.  You'd need to rewrite it so it  
> > > can handle being linked into multiple executables, or you'd need  
> > > to create a new shared library, put the routine in it, and ship  
> > > that shared library with every executable you create.
> >
> > OK, we've got quite a bit of work to do then, all the runtime libs  
> > (gfortran, stdc++v3, gomp, ffi, java)  link on libgcc_s.1.dylib
>
> That's normal, every program and shared library on Darwin does that.

I'm probably being dumb here, but some things are still not adding up  
in my mind...

(a) my understanding (looking at the output of  Wl,-t and Wl,- 
whyload) is that libgcc_s.1 is ignored completely and the symbols are  
resolved from libSystem

(b) If it is mandatory that gcc is configured with --with-slibdir=/ 
usr/lib for darwin, this should be mentioned somewhere (and I agree,  
at that point, our cause looks pretty bleak).

(c) If we make the runtimes dependent on a specific version of the  
system ; then shouldn't the runtimes reference that specific version  
(e.g libgcc_s.10.4.dylib)?
(at the moment they all reference libgcc_s.1).

(d) currently, (AFAICT*) the runtimes link against, and are checked  
against, the libgcc_s.1 that has *just been built* ;  some trouble  
could lie ahead when an application built with that is deployed onto  
a live system.  We also take the test output as indicative of the  
compiler behavior - clearly, that can't be trusted if we test with a  
different library set from the deployment.

* using DYLD_PRINT_LIBRARIES,  LD_TRACE_* , and looking at crashlogs  
from crashed test cases.

(e) Surely I should be able to (per executable) replace any symbol  
(excluding ex. handlers, unless I replace the whole facility) with a  
more up-to-date version - by referencing the appropriate library?

sorry for all the noise ... but your explanations are most valued,
Iain