[Bug target/47558] New: 163267 breaks exception traceback in xplor-nih

[Bug target/47558] New: 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

           Summary: 163267 breaks exception traceback in xplor-nih
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: howarth@nitro.med.uc.edu


The commit...

r163267 | iains | 2010-08-15 15:15:55 -0400 (Sun, 15 Aug 2010) | 7 lines


rationalize libgcc stub & static lib linkage on Darwin 9 & 10.

        * config/darwin.h (REAL_LIBGCC_SPEC): Remove libgcc_s.10.5 stub for 
        Darwin10.  Do not link libgcc.a for Darwin >= 9.

breaks the exception traceback in xplor-nih on x86_64-apple-darwin such that
the dipCoup.inp test in xplor-nih fails with...


-------------------------------------------------------------------------------
 -- POWELL ------ step=      5 --- stepsize=  0.020455 --- energy evals=    2
--
 | Etotal =181.583    grad(E)=4.894      E(BOND)=6.068      E(ANGL)=160.218   
|
 | E(IMPR)=5.596      E(XDIP)=9.701                                           
|

-------------------------------------------------------------------------------
Powell::step: irregular exit: Line search abandoned: gradient may be incorrect
../bin/xplor: line 499:  6658 Abort trap             
/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/xplor

This failure occurs in gcc 4.6 from r163267 including current gcc trunk. I
notice that from this revision
forward, the linkages in the xplor-nih build show changes of the form...

 libintVar.dylib:
@@ -21,14 +19,12 @@
    
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
(compatibility version 1.0.0, current version 219.0.0)
    
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
(compatibility version 1.0.0, current version 219.0.0)
     /Users/howarth/dist/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.15.0)
-    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
625.0.0)
     /Users/howarth/dist/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
     /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.1)

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #4 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 00:14:17 UTC ---
(In reply to comment #3)
> we keep going round this loop --- by making this change; you are replacing the
> unwinder in libSystem with the one in FSF libgcc_s.

Why do you say that? I am returning the linkage to...

    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
625.0.0)
    /Users/howarth/dist/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.1)

which if anything should insure that the system unwinder related calls are used
rather
than those in the FSF libgcc_s. Please reread...

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html

My understanding from this was that the system unwinder was protected by magic
symbols
and would ALWAYS be used. However by putting /usr/lib/libgcc_s.1.dylib back in
front of /Users/howarth/dist/lib/libgcc_s.1.dylib, we may be insuring that any
other
unprotected unwinder related symbols come from the Apple's libgcc and not FSF
libgcc.
I think at this point that the important question is where do we have
demonstrated breakage.
I don't recall we ever had an explicit example demonstrating that the remaining
change in
r163267 was essential.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #5 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 00:32:07 UTC ---
Iain,
   I think you are confused about what reverting r163267 achieves. I believe
the remaining change in r163267 was left in place because we were under the
impression that the magic symbols in darwin10 eliminated the need to place
/usr/lib/libgcc_s.dylib in front of the FSF libgcc_s.1.dylib in the linkage
order. This apparently isn't true. There must be some unprotected symbol that
Apple forget to protect. Otherwise restoring the strict behavior of having the
order...

    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
625.0.0)
    /Users/howarth/dist/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.1)

(which is what we do for darwin9) wouldn't eliminate the exception issues in
xplor-nih. Again note that on darwin9, we have linkages like...

libffi.dylib:
    /sw/lib/gcc4.6/lib/libffi.4.dylib (compatibility version 5.0.0, current
version 5.1.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
1.0.0)
    /sw/lib/gcc4.6/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
111.1.5)

so reverting the remainder of r163267 is just restoring the previous behavior
where didn't assume that the magic symbols in darwin10 would handle this for
us.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #6 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 03:55:13 UTC ---
We should be very concerned about the fact that on the darwin10 builds of gcc
trunk, we don't prefix the same symbols in the FSF gcc's libgcc_s.1.dylib with
$ld$hide$os10.4$, $ld$hide$os10.5$ and $ld$hide$os10.6$ as the system
libgcc_s.1.dylib . It is entirely uncertain how the darwin linker behaves when
only shown...

    /sw/lib/gcc4.6/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.10)

as a linkage since /sw/lib/gcc4.6/lib/libgcc_s.1.dylib contains the same
symbols as in
/usr/lib/libgcc_s.1.dylib but without these magic prefixes. It is an open
question if the stub
mechanism is properly engaged in this case. I am trying to getting a
clarification from the Apple linker developer on how serious this problem is.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #7 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 04:01:52 UTC ---
Also note that on darwin10...

lrwxr-xr-x  1 root  wheel     17 Nov  4 19:37 libgcc_s.1.dylib ->
libSystem.B.dylib
lrwxr-xr-x  1 root  wheel     19 Nov  4 20:32 libgcc_s.10.4.dylib ->
libgcc_s.10.5.dylib
-rwxr-xr-x  1 root  wheel  40668 Apr 23  2010 libgcc_s.10.5.dylib

So that when we only have the linkage...

    /sw/lib/gcc4.6/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.10)

the linker is exposed to a libgcc_s.1.dylib with unprefixed symbols first
whereas with...

    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
625.0.0)
    /sw/lib/gcc4.6/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.10)

It is actually being linked against libSystem first (which contains the
prefixed symbols) but through a symlink.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #8 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 06:10:32 UTC ---
Actually a backtrace confirms that current gcc trunk is broken and the missing
linkage on /usr/lib/libgcc_s.1.dylib is causing the wrong unwinder to be
used...

howarth% ../bin/xplor -debug gdb 
GNU gdb 6.3.50-20050815 (Apple version gdb-1510) (Wed Sep 22 02:45:02 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries ............... done

(gdb) r < dipCoup.inp
Starting program: /Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/xplor <
dipCoup.inp
Reading symbols for shared libraries .++++++++++++++....... done
               Xplor-NIH version 2.27-custom 
...


-------------------------------------------------------------------------------
 -- POWELL ------ step=      5 --- stepsize=  0.020455 --- energy evals=    2
--
 | Etotal =181.583    grad(E)=4.894      E(BOND)=6.068      E(ANGL)=160.218   
|
 | E(IMPR)=5.596      E(XDIP)=9.701                                           
|

-------------------------------------------------------------------------------
Powell::step: irregular exit: Line search abandoned: gradient may be incorrect

Program received signal SIGABRT, Aborted.
0x00007fff87c05616 in __kill ()
(gdb) bt
#0  0x00007fff87c05616 in __kill ()
#1  0x00007fff87ca5cca in abort ()
#2  0x00000001020b37a6 in uw_init_context_1 (context=0x7fff5fbfc4b0,
outer_cfa=0x7fff5fbfc6e0, outer_ra=0x10190eb12) at
../../../gcc/libgcc/../gcc/unwind-dw2.c:1265
#3  0x00007fff5fbfc920 in ?? ()
#4  0x00007fff87c070a2 in __sflush ()
(gdb) 

If we were properly executing in the system unwinder, which lacks debug code,
we wouldn't end up with a backtrace through
../../../gcc/libgcc/../gcc/unwind-dw2.c:1265 in the FSF gcc sources.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 09:08:53 UTC ---
Jack,

The linkage of libs (with trunk darwin.h) is like this:

libgcc_ext.dylib ---> exports our additional symbols (ONLY)**
libSystem ---- > contains the annotated system symbols.

** this causes the reference to /my/install/path/libgcc_s.1.dylib to be
inserted into the exe.

As below:
===

mini-02-sno:gcc-4-6-trunk-build$ uname -a 
Darwin mini-02-sno.local 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10
18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386 i386

====

mini-02-sno:gcc-4-6-trunk-build$ cat /Volumes/ScratchCS/tests/linkage.c
/* This is not meant to work or do anything useful !!! 
   -- sole purpose is to allow examination of linkage.  */
int main (void)
{
static __thread i;  <<=== make it link our ext lib.
  i+i; 
  _Unwind_Resume ((void *)0); <<== make it link libSystem (we expect - NOT from
our ext.)
  return i;
}

======

mini-02-sno:gcc-4-6-trunk-build$ ./gcc/xgcc -Bgcc
/Volumes/ScratchCS/tests/linkage.c -o tt

mini-02-sno:gcc-4-6-trunk-build$ nm -mv tt
0000000100000f80 (__TEXT,__stub_helper) non-external (was a private external) 
stub helpers
0000000100001060 (__DATA,__data) external _NXArgc
0000000100001068 (__DATA,__data) external _NXArgv
                 (undefined [lazy bound]) external __Unwind_Resume (from
libSystem) <<<=== correct
                 (undefined [lazy bound]) external ___emutls_get_address (from
libgcc) <<<=== correct
0000000100001080 (__DATA,__data) non-external ___emutls_v.i.1606
0000000100001078 (__DATA,__data) external ___progname
0000000100000f38 (__TEXT,__text) non-external __dyld_func_lookup
0000000100000000 (absolute) [referenced dynamically] external
__mh_execute_header
0000000100001070 (__DATA,__data) external _environ
                 (undefined [lazy bound]) external _exit (from libSystem)
0000000100000f3e (__TEXT,__text) external _main
                 (undefined) external dyld_stub_binder (from libSystem)
0000000100000f24 (__TEXT,__text) non-external dyld_stub_binding_helper
0000000100000ee8 (__TEXT,__text) external start

====

mini-02-sno:gcc-4-6-trunk-build$ DYLD_PRINT_LIBRARIES=1 ./tt
dyld: loaded: /Volumes/GCC/gcc-4-6-trunk-build/./tt
dyld: loaded:
/GCC/gcc-4-6-install/lib/gcc/x86_64-apple-darwin10/4.6.0/libgcc_s.1.dylib
dyld: loaded: /usr/lib/libSystem.B.dylib
dyld: loaded: /usr/lib/system/libmathCommon.A.dylib
Segmentation fault <<<< === no surprise, the program is not meant to work

====

although the program does not work - you can
(a) install your built gcc [without modifying darwin.h]
(b) compile the prog with debug and step through to find that the
_Unwind_Resume that is called __is__ the one from libSystem.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 13:25:31 UTC ---
two more minor points.

1/ the trunk lib specs do the same as gcc-4.2.1(apple local)

2/ there are no exported symbols for 10.6 in /usr/lib/libgcc_s.10.5.dylib (they
are all $add$os10.4 or 10.5)

so, you might ask the question "why does changing that spec make *any*
difference" ?

(it should only be an improvement in efficiency, no change in symbols).

.. debugging that will probably get you to the answer to where the real problem
lies.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #11 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 13:51:52 UTC ---
Created attachment 23195
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23195
build log for xplor-nih 2.2.7 under gcc trunk

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #12 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 13:53:18 UTC ---
Created attachment 23196
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23196
otool -L output for xplor-nih binaries

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #13 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 13:56:18 UTC ---
It was be true for the simple case that the reduced linkage is fine but somehow
the xplor-nih building is exposing a corner case we haven't thought of. I have
uploaded a full build log for xplor-nih which was 
created with...

cd xplor-nih-2.27
set path= ( '/Users/howarth/dist/bin' $path )
make

and the compilers show up as...


[frodo:~/xplor-nih-2.27] howarth% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.6.0
Configured with: ../gcc/configure --enable-checking=release
--prefix=/Users/howarth/dist --with-gmp=/sw --with-ppl=/sw --with-cloog=/sw
--with-mpc=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-languages=c,c++,fortran --enable-cloog-backend=legacy
Thread model: posix
gcc version 4.6.0 20110201 (experimental) (GCC) 
[frodo:~/xplor-nih-2.27] howarth% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.6.0
Configured with: ../gcc/configure --enable-checking=release
--prefix=/Users/howarth/dist --with-gmp=/sw --with-ppl=/sw --with-cloog=/sw
--with-mpc=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-languages=c,c++,fortran --enable-cloog-backend=legacy
Thread model: posix
gcc version 4.6.0 20110201 (experimental) (GCC) 
[frodo:~/xplor-nih-2.27] howarth% gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.6.0
Configured with: ../gcc/configure --enable-checking=release
--prefix=/Users/howarth/dist --with-gmp=/sw --with-ppl=/sw --with-cloog=/sw
--with-mpc=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-languages=c,c++,fortran --enable-cloog-backend=legacy
Thread model: posix
gcc version 4.6.0 20110201 (experimental) (GCC)

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 14:37:39 UTC ---
the difference caused by including a reference to "/usr/libgcc_s.xxx" is to
allow a libgcc_s appearing in a DYLD_LIBRARY_PATH (or a fallback path in the
compiler's list) to over-ride ... 

have you (or does the build process) set a DYLD_LIBRARY_PATH ?

another possibility is a corrupted, stale or erroneous build of one of those
libraries that refers to _Unwind_xxxx in FSF libgcc_s.1.dylib (how it manages
that would bear some inspection).

I've checked recent trunk for 10.6 and
(a) libgcc_ext.dylib does NOT export _Unwind_xxxxx
(b) /usr/libgcc_s.10.5.dylib is just a stub pointing to libSystem.dylib.

so if you've manage to resolve _Unwind_xxxx from FSF libgcc_s then the two top
choices are:
either there is a dodgy -L in the build process 
or you've got a DYLD_LIBRARY_PATH somewhere ...

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #15 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 15:11:51 UTC ---
DYLD_LIBRARY_PATH is unset when xplor is started. Also remember that your test
case in comment 9 is insufficient to reproduce the behavior of xplor-nih. The
code calling the unwinder should be placed in a shared library and then called
from a main program. I don't see anything in the following linkages which
should cause a problem.

gcc -fdefault-integer-8 -dynamiclib -o libfft.dylib dsint.o dsinti.o dcfftf.o
dcfftb.o dcffti.o drffti.o drfftf.o drfftb.o zffti.o zfftf.o zfftb.o ctrans.o
zfft1d.o zfft2d.o zfft3d.o ftrans.o zmp_fft.o zscal_fft.o zprod_fft.o fft_ftn.o
-flat_namespace -undefined suppress -single_module    -lcrypto -lblas 

gcc -fdefault-integer-8 -dynamiclib -o libpppack.dylib cubspl.o ppvalu.o
intdy.o xerrwv.o -flat_namespace -undefined suppress -single_module    -lcrypto 

gcc -fdefault-integer-8 -dynamiclib -o libspecfun.dylib gamma.o rjbesl.o
ribesl.o -flat_namespace -undefined suppress -single_module    -lcrypto 

g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress
-single_module dpApi.o vmd.o vmdInter.o tclStream.o dpStream.o ssStream.o
publicVMDInter.o thread.o -o libvmd.dylib    -lcrypto

g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress
-single_module dinternal.o dint-atom.o dint-node.o dint-loop.o dint-step.o
dint-powell.o dint-conmin.o dint-simplex.o dint-pc6.o dint-xplor.o publicIVM.o
-o libintVar.dylib    -lcrypto
-L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ -llapack -lblas  

g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress
-single_module maketables.o get.o study.o pcre.o -o libpcre.dylib    -lcrypto

g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress
-single_module simulation.o xplorSimulation.o xplorWrap.o atom.o atomSel.o
atomSelAction.o derivList.o pdbTool.o ensembleSimulation.o simulationWorld.o
xplorPot.o mmapAlloc.o semaphore.o mutex-sem.o randomNum.o potList.o avePot.o
modified.o enumNameMap.o dihedral.o ensemblePot.o xplorWrapProc.o
coordComparer.o atomSelLang.o atomSelLangYacc.o mmapMalloc.o -o libcommon.dylib
   -lcrypto -L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ -lpcre
-llapack -lblas 

g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress
-single_module surf.o io.o compute.o dual.o utils.o lp.o chull.o tessel_cases.o
tessel_patches.o tessel_convex.o tessel_concave.o tessel_torus.o surfDiff.o -o
libsurfD.dylib    -lcrypto
-L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ -lspecfun -llapack -lblas 

g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress
-single_module noePot.o atomProb.o rdcPot1.o csaPot.o jCoupPot.o shapePot.o
atomDensity.o probDistPot.o cosRatioPot.o ncsPot.o prePot.o rdcWavePot.o
varTensor.o surfaceArea.o psolPot.o orderPot.o posRMSDPot.o utils.o
posSymmPot.o sphereFun.o volume.o planeDistPot.o selNBPot.o gyrPot.o
cstMagPot.o diffPot.o relaxRatioPot.o distSymmPot.o sardcPot.o
surfTessellation.o torsionDBPot.o nbTargetPot.o solnScatPot.o -o
libnmrPot.dylib    -lcrypto
-L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ -lspecfun -lsurfD
-llapack -lblas 

g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress
-single_module PeakAssignment.o Peak.o MarvinNOEPotential.o ShiftAssignment.o
EquivPeakAssignmentSet.o -o libmarvin.dylib    -lcrypto

gcc -fdefault-integer-8 -dynamiclib -o libxplor.dylib xfft.o xdofft.o
dtorsion.o rotman.o array.o genic.o prot.o tsearch.o xmwrite.o carb.o csa.o
geomty.o psfio.o update.o xparse.o hbonds.o usersb.o xpeakpik.o corman.o
hbuild.o rotate.o util.o coup.o initia.o rotlsq.o vcorr.o xpred.o cstack.o
intcor.o vcorrfft.o xprobab.o cstran.o matrix.o rsearch.o vector.o xprox.o
distan.o mmdisg.o rtfio.o xasymm.o xreduce.o drigid.o modes.o rxconv.o
xdeclare.o xrefin.o mrigid.o rxprin.o xdo.o xrmani.o dynamc.o nbonds.o rxrefi.o
xropti.o dynanl.o ncs.o rxsetu.o xdofried.o xscale.o noe.o sbound.o xdohelp.o
xsfsele.o dynlng.o onebond.o segmnt.o xfalgebra.o xshow.o eangle.o packing.o
selrpn.o xsigmaa.o ebond.o parmio.o parser.o xmalgebra.o xskel.o enbond.o
shake.o xmask.o xstats.o energy.o pick.o sort.o xmaverage.o xsymm.o etor.o
plane.o string.o xmphisto.o xtarget.o expression.o powell.o surfac.o xmpsele.o
fastnb.o power.o test.o xmread.o collapse_rgyr.o xrama.o trio_faster_newderiv.o
susc_anis.o rama_gaussians.o orientations.o xdipolar_coup.o diff_anis.o
anisotropy.o angledb.o vectangl.o fantacross.o fantalin.o xangle.o xccr.o
xfantaccr.o xfantadipo.o xdipo_pcs.o xdipo_rdc.o xt1dist.o hbdb.o saxs.o pcsa.o
ss_orient.o xadc.o hb_dist_angle.o aria.o ariman.o ariass.o aribac.o arical.o
arivio.o bonded.o ace.o pmag.o tens_dip_e2.o tenso.o slink.o fxrefin.o
fxparse.o fwrite.o pxrefin.o pxtarget.o fxmap.o pxparse.o pxmani.o xmap.o
zpacking.o ppacking.o fenergy.o sebond.o seangl.o setor.o darwin64time.o
osx_x86_64.o -flat_namespace -undefined suppress -single_module    -lcrypto 
-L/Users/howarth/dist/lib -lgfortran -llapack -lblas  -lblas
-L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ 

gcc -fdefault-integer-8 -dynamiclib -o libxplorCmd.dylib coorio.o dynio.o
xplorFunc.o ps300.o python_stubs.o tcl_stubs.o ccalls.o cnshelp.o i1mach.o
-flat_namespace -undefined suppress -single_module    -lcrypto 
-L/Users/howarth/dist/lib -lgfortran -llapack -lblas  -lblas
-L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ 
-L/Users/howarth/dist/lib -lgfortran -llapack -lblas  -lblas    -lcrypto 
-L/Users/howarth/dist/lib -lgfortran -llapack -lblas  -lblas
-L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ 

gcc -o xplor xplor.o  \
       \
      -L. -lxplorCmd -lxplor
-L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ -lfft -lintVar -lvmd
-lnmrPot -lcommon -lmarvin  \
         -lcrypto  -L/Users/howarth/dist/lib -lgfortran -llapack -lblas  -lblas
-L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ \

As for DYLD_LIBRARY_PATH, changing...


+++ xplor    2011-02-01 10:04:59.000000000 -0500
@@ -89,6 +89,8 @@

 if [ `uname` = "Darwin" ]; then
     LD_LIBPATH_VAR=DYLD_LIBRARY_PATH
+    echo "DYLD_LIBRARY_PATH = ",$DYLD_LIBRARY_PATH
+    echo "PATH = ",$PATH
 fi

 if [ "$LD_LIBRARYN32_PATH" != "" -a `uname` = "IRIX64" ]; then

shows...

DYLD_LIBRARY_PATH = ,
PATH =
,/usr/bin:/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/X11/bin

Perhaps r163267 is fragile to certain combination of linker flags (like
-flat_namespace)?

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 15:26:15 UTC ---
(In reply to comment #15)


> Perhaps r163267 is fragile  to certain combination of linker flags (like
> -flat_namespace)?

"fragile" LOL... 

man ld:

   -flat_namespace
                 Alters how symbols are resolved at build time and runtime. 
With -two_levelnamespace (the default), the linker only searches
                 dylibs on the command line for symbols, and records in which
dylib they were found.  With -flat_namespace, the linker searches
                 all dylibs on the command line and all dylibs those original
dylibs depend on.  The linker does not record which dylib an
                 external symbol came from, so at runtime dyld again searches
all images and uses the first definition it finds.  In addition,
                 any undefines in loaded flat_namespace dylibs must be
resolvable at build time.

--  you are defeating the mechanism that is used to supply the _ext symbols
from a different library.
If use if this flag is, actually, necessary then we need to alter the whole
mechanism for the _ext to build a distinctly named lib.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 15:50:44 UTC ---
I guess you could make the requirement to link libSystem before (and after)
libgcc_ext explicit like this:

Index: gcc/config/darwin10.h
===================================================================
--- gcc/config/darwin10.h    (revision 169471)
+++ gcc/config/darwin10.h    (working copy)
@@ -23,3 +23,6 @@ unwinder in libSystem is fixed to digest new epilo

 #undef LIB_SPEC
 #define LIB_SPEC "%{!static:-no_compact_unwind -lSystem}"
+
+#undef  LINK_GCC_C_SEQUENCE_SPEC
+#define LINK_GCC_C_SEQUENCE_SPEC "%L %G %L"

=======

better than having a side-effect of a stub library achieving the same thing.

but it would still be worth knowing how many (if any) programs actually require
flag namespace.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #18 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 15:57:30 UTC ---
(In reply to comment #17)
> I guess you could make the requirement to link libSystem before (and after)
> libgcc_ext explicit like this:

you would also need to ensure that libSystem was before
/install/path/to/my/libgcc_s.1.dylib in the search paths at runtime... 

> but it would still be worth knowing how many (if any) programs actually require
> flag namespace.

... because if this is a large requirement then we really need to change the
way the _ext is done (for reasons that should be evident from this and the
preceding comment),.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #19 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 15:59:30 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
> 
> 
> > Perhaps r163267 is fragile  to certain combination of linker flags (like
> > -flat_namespace)?
> 
> "fragile" LOL... 
> 

Considering that Apple has always recommended the use of that flag for porting
unix software...

http://developer.apple.com/library/mac/#documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html%23//apple_ref/doc/uid/TP40002850-TPXREF101

(see the section on Understanding Two-Level Namespaces), it really is not a
very funny bug.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 16:32:13 UTC ---
(In reply to comment #19)
> (In reply to comment #16)
> > (In reply to comment #15)
> > 
> > 
> > > Perhaps r163267 is fragile  to certain combination of linker flags (like
> > > -flat_namespace)?
> > 
> > "fragile" LOL... 
> > 
> 
> Considering that Apple has always recommended the use of that flag for porting
> unix software...
> 
> http://developer.apple.com/library/mac/#documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html%23//apple_ref/doc/uid/TP40002850-TPXREF101
> 
> (see the section on Understanding Two-Level Namespaces), it really is not a
> very funny bug.

I don't consider any bug funny ; 
however instructing the linker to ignore two-level-namespace is not a
'fragility' on the part of the compiler or its specs.     

The fault may be considered to be

(a)  in relying on the two-level-namespace in our extension design if there is
a requirement for flat-namespace at the same time as the extensions. 
[FWIW: originally I posted a patch for a separate lib, which was felt by
reviewers to be inefficient, hence the use of the stubs and two-levels.]

(b) the build process for the application uses -flat_namespace but is not
sufficiently explicit about library paths and library ordering.  [using flat
namespace requires that you make sure that the libs appear in the order you
want them].

---

note, despite the document comments:
the use of two level namespace is the Apple default.
the Apple tools use the same library ordering that trunk does.

In the short-term, we can either revert the patch or apply the alternative [any
preference Mike?] which will force the library ordering (after we spent all
that effort to ensure that libSystem was _not_ linked first by filtering out
-lm etc.)

In the longer term, if this really is the 'norm' we will have to re-do the
libgcc_ext to be a non-stub library.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #21 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 16:40:17 UTC ---
(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #16)
> > > (In reply to comment #15)


> In the short-term, we can either revert the patch or apply the alternative [any
> preference Mike?] which will force the library ordering (after we spent all
> that effort to ensure that libSystem was _not_ linked first by filtering out
> -lm etc.)

we would also need something like libgcc_s.10.5 libgcc_ext.10.5 libgcc_s.10.5
for 10.5 and similar for 10.4.
 :-(

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #22 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 16:57:04 UTC ---
My only comment is that the likely users of FSF gcc are also likely builders of
ported unix code. So gcc 4.6 needs a big fat warning that existing ported unix
code will have to be vetted for the use of flat-namespace and the linkages
manually adjusted. Otherwise will users of gcc 4.6 will unknowingly miscompile
lots of existing unix code. Since we don't link this way in gcc 4.5, I don't
see why we can't just revert the behavior and postpone this change until gcc
4.7 when it can be more carefully done.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #23 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 17:28:36 UTC ---
(In reply to comment #22)
> My only comment is that the likely users of FSF gcc are also likely builders of
> ported unix code. So gcc 4.6 needs a big fat warning that existing ported unix
> code will have to be vetted for the use of flat-namespace and the linkages
> manually adjusted. Otherwise will users of gcc 4.6 will unknowingly miscompile
> lots of existing unix code. Since we don't link this way in gcc 4.5, I don't
> see why we can't just revert the behavior and postpone this change until gcc
> 4.7 when it can be more carefully done.

I am concerned that we push the balloon in one place and it pops out in
another.
We have made a lot of effort to avoid libSystem linkage before the ext to avoid
other reported issues with unwinding and Java IIRC.  I am not too keen simply
to go round in circles (we need proper fixes, of course).

This might be a reasonable compromise until the proper fixes are forthcoming:


Index: gcc/config/darwin.h
===================================================================
--- gcc/config/darwin.h    (revision 169490)
+++ gcc/config/darwin.h    (working copy)
@@ -327,12 +331,16 @@ extern GTY(()) int darwin_ms_struct;
    "%{static-libgcc|static: -lgcc_eh -lgcc;                   \
       shared-libgcc|fexceptions|fgnu-runtime:                   \
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4)       \
-       %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
+       %{flat_namespace:                           \
+         %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5)       \
+        :%:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)}\
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
        -lgcc ;                                   \
       :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \
-       %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
+       %{flat_namespace:                           \
+         %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5)       \
+        :%:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)}\
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
        -lgcc }"

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #24 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 17:49:34 UTC ---
(In reply to comment #23)
> (In reply to comment #22)
> > My only comment is that the likely users of FSF gcc are also likely builders of
> > ported unix code. So gcc 4.6 needs a big fat warning that existing ported unix
> > code will have to be vetted for the use of flat-namespace and the linkages
> > manually adjusted. Otherwise will users of gcc 4.6 will unknowingly miscompile
> > lots of existing unix code. Since we don't link this way in gcc 4.5, I don't
> > see why we can't just revert the behavior and postpone this change until gcc
> > 4.7 when it can be more carefully done.
> 
> I am concerned that we push the balloon in one place and it pops out in
> another.
> We have made a lot of effort to avoid libSystem linkage before the ext to avoid
> other reported issues with unwinding and Java IIRC.  I am not too keen simply
> to go round in circles (we need proper fixes, of course).
> 
> This might be a reasonable compromise until the proper fixes are forthcoming:

well a couple of hiccups ... this seems OK on Darwin9 --- could you try D10?


Index: gcc/config/darwin.h
===================================================================
--- gcc/config/darwin.h    (revision 169490)
+++ gcc/config/darwin.h    (working copy)
@@ -327,12 +331,16 @@ extern GTY(()) int darwin_ms_struct;
    "%{static-libgcc|static: -lgcc_eh -lgcc;                   \
       shared-libgcc|fexceptions|fgnu-runtime:                   \
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4)       \
-       %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
+       %{Zflat_namespace:                           \
+         %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5);       \
+        :%:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)}\
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
        -lgcc ;                                   \
       :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \
-       %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
+       %{Zflat_namespace:                           \
+         %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5);       \
+        :%:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)}\
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
        -lgcc }"

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #25 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 18:22:45 UTC ---
Again, I would note Nick's original comments on these issues...

 This may be that the libgcc_s.dylib based unwinder is incompatible  
 with the darwin unwinder.  You cannot mix and match the two.  One of  
 the lines from the bugzilla comments shows:
 /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
 being used.   That will not work.  All of the libgcc_s.dylib  
 functionality has been subsumed into libSystem.dylib on SnowLeopard  
 (darwin10).   The gcc compiler that shipped with SnowLeopard leaves  
 the -lgcc_s off the link line when targeting SnowLeopard.   If there  
 is a newer libgcc_s with new functions added, then the link line needs  
 to change to "-lSystem -lgcc_s", that way the linker will find the  
 most routines in libSystem.dylib and only the new functions from  
 libgcc_s.dylib.  Thus all linkage units will use the same unwinder.

So for compatibility with any Apple gcc built software, we should never
allow the FSF gcc unwinder to become operational under any circumstances.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #26 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 18:40:53 UTC ---
(In reply to comment #25)
> Again, I would note Nick's original comments on these issues...


> So for compatibility with any Apple gcc built software, we should never
> allow the FSF gcc unwinder to become operational under any circumstances.

and that is how we have the design (the comment  applies to all versions of
Darwin, not just 10).

the only case where using the FSF unwinder would make any sense  is for
stand-alone code which does not link any system libs - not a likely scenario
for anything other than test-code.

You can defeat the design in various ways (e.g. setting DYLD_LIBRARY_PATHs) but
there's nothing we can do about that - everything is working as intended - if
the User instructs the compiler/linker to do incompatible things there is
little we can do.

The residual issue is that we are (99.9% likely) issuing unwind information
which is incompatible with the Darwin system unwinders - there have been fixes
posted for this, and it needs re-visiting - but, again, nothing to do with the
PR at hand.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #27 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 19:10:35 UTC ---
I am testing the patch proposed in Comment 24 on darwin10 now.
Don't we also have to handle Zforce_flat_namespace?

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #28 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01 20:08:51 UTC ---
Strangely this is insufficient to eliminate the crash (which still ends up in
the FSF libgcc unwinder)...

 -- POWELL ------ step=      5 --- stepsize=  0.020455 --- energy evals=    2
--
 | Etotal =181.583    grad(E)=4.894      E(BOND)=6.068      E(ANGL)=160.218   
|
 | E(IMPR)=5.596      E(XDIP)=9.701                                           
|

-------------------------------------------------------------------------------
Powell::step: irregular exit: Line search abandoned: gradient may be incorrect

Program received signal SIGABRT, Aborted.
0x00007fff87c05616 in __kill ()
(gdb) bt
#0  0x00007fff87c05616 in __kill ()
#1  0x00007fff87ca5cca in abort ()
#2  0x00000001020bd7a6 in uw_init_context_1 (context=0x7fff5fbfc290,
outer_cfa=0x7fff5fbfc4c0, outer_ra=0x101917b12) at
../../../gcc/libgcc/../gcc/unwind-dw2.c:1265
#3  0x00007fff5fbfc700 in ?? ()
#4  0x00007fff87c070a2 in __sflush ()
(gdb) 

despite the fact that the linkages in gcc with -v show for -flat_namespace...

g++ -dynamiclib -fdefault-integer-8 -flat_namespace -undefined suppress
-single_module dinternal.o dint-atom.o dint-node.o dint-loop.o dint-step.o
dint-powell.o dint-conmin.o dint-simplex.o dint-pc6.o dint-xplor.o publicIVM.o
-v -o libintVar.dylib -lcrypto
-L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ -llapack -lblas
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.6.0
Configured with: ../gcc/configure --enable-checking=release
--prefix=/Users/howarth/dist --with-gmp=/sw --with-ppl=/sw --with-cloog=/sw
--with-mpc=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-languages=c,c++,fortran --enable-cloog-backend=legacy
Thread model: posix
gcc version 4.6.0 20110201 (experimental) (GCC) 
COMPILER_PATH=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.6.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.6.0/
LIBRARY_PATH=/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.6.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.6.0/4.6.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.6' '-Zdynamiclib'
'-fdefault-integer-8' '-Zflat_namespace' '-undefined' 'suppress'
'-Zsingle_module' '-v' '-o' 'libintVar.dylib'
'-L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/' '-shared-libgcc'
'-mtune=core2'
 /Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/collect2
-dynamic -dylib -arch x86_64 -flat_namespace -macosx_version_min 10.6.6
-single_module -undefined suppress -weak_reference_mismatches non-weak
-undefined suppress -o libintVar.dylib -ldylib1.10.5.o
-L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/
-L/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.6.0/4.6.0
-L/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.6.0/4.6.0/../../..
dinternal.o dint-atom.o dint-node.o dint-loop.o dint-step.o dint-powell.o
dint-conmin.o dint-simplex.o dint-pc6.o dint-xplor.o publicIVM.o -lcrypto
-llapack -lblas -lstdc++ -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -no_compact_unwind
-lSystem -v
collect2 version 4.6.0 20110201 (experimental) (x86_64 Darwin)
/usr/bin/ld -dynamic -dylib -arch x86_64 -flat_namespace -macosx_version_min
10.6.6 -single_module -undefined suppress -weak_reference_mismatches non-weak
-undefined suppress -o libintVar.dylib -ldylib1.10.5.o
-L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/
-L/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.6.0/4.6.0
-L/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.6.0/4.6.0/../../..
dinternal.o dint-atom.o dint-node.o dint-loop.o dint-step.o dint-powell.o
dint-conmin.o dint-simplex.o dint-pc6.o dint-xplor.o publicIVM.o -lcrypto
-llapack -lblas -lstdc++ -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -no_compact_unwind
-lSystem -v
@(#)PROGRAM:ld  PROJECT:ld64-97.17
Library search paths:
    /Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/
    /Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.6.0/4.6.0
    /Users/howarth/dist/lib
    /usr/lib
    /usr/local/lib
Framework search paths:
    /Library/Frameworks/
    /System/Library/Frameworks/

In fact, the only thing left which doesn't have the initial linkage on
/usr/lib/libgcc_s.1.dylib. Is the xplor executable itself. Only when I relink
that file with...

gcc -o xplor xplor.o -L. -lxplorCmd -lxplor
-L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/ -lfft -lintVar -lvmd
-lnmrPot -lcommon -lmarvin -lcrypto -L/Users/howarth/dist/lib -lgfortran
-llapack -lblas -lblas -L/Users/howarth/xplor-nih-2.27/bin.Darwin_10_x86_64/
/usr/lib/libgcc_s.1.dylib

so that I have...

    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.1)
    /Users/howarth/dist/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)

does the crash in the dipCoup.inp test case disappear.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #29 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 23:53:31 UTC ---
(In reply to comment #28)
> Strangely this is insufficient to eliminate the crash (which still ends up in
> the FSF libgcc unwinder)...

> In fact, the only thing left which doesn't have the initial linkage on
> /usr/lib/libgcc_s.1.dylib. Is the xplor executable itself. 

Well, the failure in that case seems plausible ... 

by linking the libraries '-flat_namespace'  one has elected to have their
dependencies satisfied from whatever order the libraries are presented by the
next stage  of linking...

... So, when you link the final exe (without -flat_namespace) if the FSF
libgcc_s is presented first the dependent libs will use that - they have no
information to tell them that the symbols should really come from somewhere
else. 

If linking the final exe is done with -flat_namespace does it work?

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #30 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-02 02:22:37 UTC ---
(In reply to comment #29)

> If linking the final exe is done with -flat_namespace does it work?

Yes, adding -flat_namespace solves the problem. I didn't realize that option
was usable for executables. I'll retry the stock gcc trunk and see if we still
need the special casing of flat_namespace.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #31 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-02 02:54:50 UTC ---
I can confirm that adding -flat_namespace to the linkage of xplor using stock
gcc trunk is insufficient to eliminate the crashes in the FSF libgcc unwinder.
So we do need both the patch from Comment 24 as well as the additional linkage
with -flat_namespace on the xplor executable. I guess we should expand the
proposed patch to also handle the case of Zforce_flat_namespace as well.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011.02.02 09:12:46
     Ever Confirmed|0                           |1

--- Comment #32 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-02 09:12:46 UTC ---
(In reply to comment #31)
> I can confirm that adding -flat_namespace to the linkage of xplor using stock
> gcc trunk is insufficient to eliminate the crashes in the FSF libgcc unwinder.

comment #30 and comment #31 are as one would expect.

adding -flat_namespace pushes the responsibility onto the build to ensure that
the libs are presented in the correct order for the design (when symbols appear
in more than one lib).  That includes libs provided by GCC - although (maybe)
the User should not have to think about that.  It also includes placement of
the libs in search paths at load/execute time (outside of our control).

One way of controlling the [link time] order (with the #24 patch in place) is
to add -flat_namespace to the exe too.   Equally, one could ensure that the
build references /usr/lib/libgcc_s.10.5.dylib or libSystem before
/my/install/path/libgcc_s.1.dylib.

Ultimately, the 'fix' to this is to ensure that the lib we install to provide
the extensions does not export the other symbols (then we won't care about of
the order of libs or DYLD_LIBRARY_PATHs).  However, this is not something for
stage 4,  and I expect that there will be test-suite fall-out when we implement
it.

So.... either

1/revert 163267 as proposed, 
Are we sure that it has no effect on any other (esp. Java) test-cases? 

2/ Patch @ comment #24 is a work-around that only changes the order for flat
namespace.

If we do #2, then we should add Zforce_flat_namespace as Jack pointed out in
comment #27 like so:

%{Zflat_namespace|Zforce_flat_namespace: 

3/ %L %G %L 
If (1) doesn't work then neither will this.

So - the permutations need reg-strapping (on Darwin 10 at least) - I'll do a
sanity check on Darwin 9 - although it should be unaffected.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #33 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-03 13:57:23 UTC ---
(In reply to comment #32)

> So.... either
> 
> 1/revert 163267 as proposed, 
> Are we sure that it has no effect on any other (esp. Java) test-cases? 
> 

I'll regression test option 1 today on darwin10. Isn't the current behavior 
(of not linking /usr/lib/libgcc_s.1.dylib) allowing any duplicate symbols 
not protected by magic symbols to gotten from FSF's libgcc_s.1.dylib
instead of libSystem? What is the desired behavior in that case?

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #34 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-03 14:21:32 UTC ---
(In reply to comment #33)
> (In reply to comment #32)
> 
> > So.... either
> > 
> > 1/revert 163267 as proposed, 
> > Are we sure that it has no effect on any other (esp. Java) test-cases? 
> > 
> 
> I'll regression test option 1 today on darwin10. Isn't the current behavior 
> (of not linking /usr/lib/libgcc_s.1.dylib) allowing any duplicate symbols 
> not protected by magic symbols to gotten from FSF's libgcc_s.1.dylib
> instead of libSystem? What is the desired behavior in that case?

No, that should not (and from the testing above, does not) happen when
two-level namespace is operating (unless you override something with
DYLD_LIBRARY_PATH etc.).  

the _ext stub _only_ exports the symbols we want to use from FSF libbgcc_s - so
the remainder should be (and are AFAICT) resolved from libSystem. 

I think, if you check, you'll find that the 'magic symbols' are only going to
affect things when using -mmacosx-version-min=10.{4,5}.

===

Darwin 9 is unaffected, as expected, by the patch @ comment 24 +
Zforce_flat_namespace.

===

FWIW, I have also made a version of t-slibgcc-darwin that exports an _ext.dylib
(and doesn't install libgcc_s) which, as I expected, causes a bunch of
regressions on D9, so that needs to wait until we resolve the unwinder issues.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #35 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-03 14:29:25 UTC ---
(In reply to comment #34)
> (In reply to comment #33)
> > (In reply to comment #32)
> > 
> > > So.... either
> > > 
> > > 1/revert 163267 as proposed, 
> > > Are we sure that it has no effect on any other (esp. Java) test-cases? 
> > > 
> > 
> > I'll regression test option 1 today on darwin10. Isn't the current behavior 
> > (of not linking /usr/lib/libgcc_s.1.dylib) allowing any duplicate symbols 
> > not protected by magic symbols 

I don't think the magic symbols are what causes the change.

when /usr/lib/libgcc_s.10.5.dylib is linked before the ext - it causes
/usr/lib/libgcc_s.1.dylib to be placed as an reference in the object.

On a live system (with no DYLD_LIBRARY_PATHS) that is fine - because
/usr/lib/libgcc_s.1.dylib is just a symlink to libSystem.dylib

However, when you run the test-suite DYLD_LIBRARY_PATH -> ${build}/gcc which
contains the FSF libgcc_s.1.dylib and that will satisfy the linkage when
libgcc_s.1.dylib appears in the exe.

Obviously, with the current trunk - we don't reference
/usr/lib/libgcc_s.1.dylib on D10 and, therefore, the lib in ${build}/gcc is
irrelevant (to D10 ... unfortunately, that's not the case for D<10).

Let's see how your testing goes.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #36 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 00:30:30 UTC ---
No regressions on x86_64-apple-darwin10 from...

Index: gcc/config/darwin.h
===================================================================
--- gcc/config/darwin.h    (revision 169789)
+++ gcc/config/darwin.h    (working copy)
@@ -327,12 +327,12 @@ extern GTY(()) int darwin_ms_struct;
    "%{static-libgcc|static: -lgcc_eh -lgcc;                   \
       shared-libgcc|fexceptions|fgnu-runtime:                   \
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4)       \
-       %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
+       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5)   \
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
        -lgcc ;                                   \
       :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \
-       %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
+       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5)   \
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
        -lgcc }"

http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg00379.html

Also checked...

gcj --main=testme -O testme.java

and

gcj --main=testme -m32 -O testme.java

Both still produce working binaries.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[mikestump at comcast dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #37 from Mike Stump <mikestump at comcast dot net> 2011-02-04 00:43:50 UTC ---
Let me know when the dust settles and you guys agree on the path forward and I
will decloak... I've been trying to avoid reading/understanding the issue...

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #38 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 01:20:05 UTC ---
Actually, I think I see the problem here. Looking at how gcc-4.2 in Snow
Leopard links, I see...
gcc -v himenoBMTxpa.c
...
/usr/libexec/gcc/i686-apple-darwin10/4.2.1/collect2 -dynamic -arch x86_64
-macosx_version_min 10.6.7 -weak_reference_mismatches non-weak -o a.out
-lcrt1.10.6.o -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64
-L/usr/lib/i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../i686-apple-darwin10/4.2.1
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../..
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccbmcsLd.o -lSystem -lgcc
-lSystem

whereas for current gcc trunk we have...

 /Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.7.0/4.6.0/collect2
-dynamic -arch x86_64 -macosx_version_min 10.6.7 -weak_reference_mismatches
non-weak -o a.out -lcrt1.10.5.o
-L/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.7.0/4.6.0
-L/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.7.0/4.6.0/../../..
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccZYYQup.o -lgcc_ext.10.5
-lgcc -no_compact_unwind -lSystem -v

So we get the wrong unwinder in xplor-nih with -flat_namepace because, while
libgcc_ext.10.5.dylib doesn't export the unwinder symbols, -lgcc will cause
/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.7.0/4.6.0/libgcc.a to provide
them. In particular, I see the symbol for ___enable_execute_stack in the FSF
libgcc.a. So what we should do is insure that FSF gcc 4.6 produces the same
sort of linkage as Apple's gcc-4.2. That is...

-lgcc_ext.10.5  -lSystem -lgcc -no_compact_unwind -lSystem

This would avoid the need for reverting r163267.

ps If I recall correctly, the Apple developers told me that they do eventually
intend to get rid of the linkage on -lgcc. Maybe that will happen in 10.7.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #39 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 01:31:30 UTC ---
Also note that on Snow Leopard...

gcc -v -mmacosx-version-min=10.5 himenoBMTxpa.c

produces...

-lgcc_s.10.5 -lgcc -lSystem

so perhaps we just need...

Index: gcc/config/darwin.h
===================================================================
--- gcc/config/darwin.h    (revision 169820)
+++ gcc/config/darwin.h    (working copy)
@@ -328,11 +328,13 @@ extern GTY(()) int darwin_ms_struct;
       shared-libgcc|fexceptions|fgnu-runtime:                   \
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4)       \
        %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
+       %:version-compare(>= 10.6 mmacosx-version-min= -lSystem)            \
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
        -lgcc ;                                   \
       :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \
        %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
+       %:version-compare(>= 10.6 mmacosx-version-min= -lSystem)            \
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
        -lgcc }"

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #40 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 01:47:16 UTC ---
Opps. It should be...

Index: gcc/config/darwin.h
===================================================================
--- gcc/config/darwin.h    (revision 169820)
+++ gcc/config/darwin.h    (working copy)
@@ -330,11 +330,13 @@ extern GTY(()) int darwin_ms_struct;
        %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
+       %:version-compare(>= 10.6 mmacosx-version-min= -lSystem)            \
        -lgcc ;                                   \
       :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \
        %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
+       %:version-compare(>= 10.6 mmacosx-version-min= -lSystem)            \
        -lgcc }"

 /* We specify crt0.o as -lcrt0.o so that ld will search the library path.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #41 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 02:39:45 UTC ---
Note that clang also precedes -lgcc with -lSystem. For
-mmacosx-version-min=10.6, it produces...

-lSystem -lgcc

(without the final -lSystem) but for -mmacosx-version-min=10.5, clang
produces...

-lgcc_s.10.5 -lgcc -lSystem

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #42 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 03:16:44 UTC ---
The patch in Comment 40 is insufficient to eliminate the exception traceback
failures in xplor-nih and it still back traces into FSF libgcc's unwinder when
it crashes. I believe...

1) We now know that FSF gcc isn't properly sandwiching -lgcc with -lSystem like
Apple gcc 4.2.1 does  or preceding -lgcc with -lSystem like clang does when
mmacosx-version-min=10.6.

2) We could consider -lgcc_ext.s.10.5 to be a corner case of the libgcc
situation and that we need...

-lSystem -lgcc_ext.s.10.5 -lgcc -no_compact_unwind -lSystem 

on mmacosx-version-min=10.6. Thus I propose...


Index: gcc/config/darwin.h
===================================================================
--- gcc/config/darwin.h    (revision 169820)
+++ gcc/config/darwin.h    (working copy)
@@ -329,11 +329,13 @@ extern GTY(()) int darwin_ms_struct;
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4)       \
        %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
+       %:version-compare(>= 10.6 mmacosx-version-min= -lSystem)            \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
        -lgcc ;                                   \
       :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \
        %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
+       %:version-compare(>= 10.6 mmacosx-version-min= -lSystem)            \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
        -lgcc }"

instead.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #43 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 03:24:02 UTC ---
I would also argue, in support of the patch in Comment 42, that it may be wrong
to assume that Apple's linker handles stubs for libgcc_s.1.dylib for
mmacosx-version-min=10.6 in the same manner as under mmacosx-version-min=10.5.
Since they now never link in libgcc_s.10.5.dylib under
mmacosx-version-min=10.6, the handling of a stub on libgcc_s.1.dylib may well
have changed (or be buggy) in the linker.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #44 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 04:48:21 UTC ---
The patch proposed in Comment 42 eliminates the exception traceback problems
when -flat_namespace is used in xplor-nih and changes our linkage to...

    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.10)
    /sw/lib/gcc4.6/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)

for mmacosx-version-min=10.6.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #45 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 04:59:06 UTC ---
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00274.html.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #46 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 05:42:13 UTC ---
Note that with the proposed patch we will pick up the failures in...

FAIL: gcc.dg/torture/builtin-math-7.c  -O0  execution test
FAIL: gcc.dg/torture/builtin-math-7.c  -O1  execution test
FAIL: gcc.dg/torture/builtin-math-7.c  -O2  execution test
FAIL: gcc.dg/torture/builtin-math-7.c  -O3 -fomit-frame-pointer  execution test
FAIL: gcc.dg/torture/builtin-math-7.c  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gcc.dg/torture/builtin-math-7.c  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gcc.dg/torture/builtin-math-7.c  -O3 -g  execution test
FAIL: gcc.dg/torture/builtin-math-7.c  -Os  execution test
FAIL: gcc.dg/torture/builtin-math-7.c  -O2 -flto -flto-partition=none 
execution test
FAIL: gcc.dg/torture/builtin-math-7.c  -O2 -flto  execution test

,PR42333, because we are once again using the ___divdc3 call from libSystem
again. I would argue that this is actually a good sign that we are not allowing
duplicate symbols from FSF libgcc to override those from libSystem.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #47 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 05:44:50 UTC ---
When the proposed patch goes into gcc trunk we should probably XFAIL
gcc.dg/torture/builtin-math-7.c for darwin10 as it is highly unlikely to be
fixed for Snow Leopard. See...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333#c47

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #48 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 05:53:00 UTC ---
Both...

[MacPro:~] howarth% gcj --main=testme -O testme.java
[MacPro:~] howarth% ./a.out
Hello

and

[MacPro:~] howarth% gcj -m32 --main=testme -O testme.java
ld: warning: in /sw/lib/libiconv.dylib, file was built for unsupported file
format which is not the architecture being linked (i386)
[MacPro:~] howarth% ./a.out
Hello

still work fine for x86_64-apple-darwin10 using the proposed patch in Comment
45.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #49 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-04 10:21:27 UTC ---
(In reply to comment #38)

> This would avoid the need for reverting r163267.

I'd rather not revert r163267 because of the behavior described in comment #35.

However, I think that libgcc_s.10.5.dylib must be interposed for the
-flat_namespace case, as described above. (i.e. patch in comment #24 +
Zforce_flat_namespace).

>  ps If I recall correctly, the Apple developers told me that they do eventually
> intend to get rid of the linkage on -lgcc. Maybe that will happen in 10.7.

I intend to get rid of it ASAP - it is only used for eprintf on x86 and eprintf
+ FP saves on PPC. 
 -- I have patches to do this (but not for 4.6).

in test, is a patch that produces the library ordering per clang/4.2.1 for 10.6
- will post later.

[ you might want to re-check
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00274.html would work with
-flat_namespace - it's not obvious how it resolves that issue].

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #50 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-04 10:52:38 UTC ---
(In reply to comment #49)
> (In reply to comment #38)
> 
> [ you might want to re-check
> http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00274.html would work with
> -flat_namespace - it's not obvious how it resolves that issue].

scratch that - I see it effectively does %L %G %L (which would be a more
conventional way to do what you've posted).  i.e. the patch in comment #17
(with no other changes).

*sigh*. if %L %G %L now apparently works - without Java regressions, then all
the effort to sort out pruning of early links to libSystem should be
irrelevant.  I guess bugs have been fixed in the 10.6.{5,6} releases.  

the (alternate) patch below produces (on 10.6.6):

$ ./gcc/xgcc -Bgcc /Volumes/ScratchCS/tests/linkage.c -o tt -v
...
... -lgcc_ext.10.5 -no_compact_unwind -lSystem -lgcc -v

$ ./gcc/xgcc -Bgcc /Volumes/ScratchCS/tests/linkage.c -o tt -v -flat_namespace
...
...  -lgcc_s.10.5 -lgcc_ext.10.5 -no_compact_unwind -lSystem -lgcc -v

$ ./gcc/xgcc -Bgcc /Volumes/ScratchCS/tests/linkage.c -o tt -v
-mmacosx-version-min=10.5
...
... -macosx_version_min 10.5 ... -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -lSystem -v

It seems to be OK on 10.6 for c++ tests.

*** However, if the patch at comment #17 works for all langs incl. Java *and*
-flat_namespace without regressions, then it is probably a better solution.  


Index: gcc/config/darwin.h
===================================================================
--- gcc/config/darwin.h    (revision 169811)
+++ gcc/config/darwin.h    (working copy)
@@ -327,15 +332,19 @@ extern GTY(()) int darwin_ms_struct;
    "%{static-libgcc|static: -lgcc_eh -lgcc;                   \
       shared-libgcc|fexceptions|fgnu-runtime:                   \
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4)       \
-       %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
+       %{Zflat_namespace|Zforce_flat_namespace:                   \
+         %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5);       \
+        :%:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)}\
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
-       -lgcc ;                                   \
+       %:version-compare(< 10.6 mmacosx-version-min= -lgcc) ;           \
       :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \
-       %:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
+       %{Zflat_namespace|Zforce_flat_namespace:                   \
+         %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5);       \
+        :%:version-compare(>< 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)}\
        %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)       \
        %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)       \
-       -lgcc }"
+       %:version-compare(< 10.6 mmacosx-version-min= -lgcc) }"

 /* We specify crt0.o as -lcrt0.o so that ld will search the library path.

Index: gcc/config/darwin10.h
===================================================================
--- gcc/config/darwin10.h    (revision 169811)
+++ gcc/config/darwin10.h    (working copy)
@@ -21,5 +21,13 @@ along with GCC; see the file COPYING3.  If not see
 /* Fix PR41260 by passing -no_compact_unwind on darwin10 and later until
 unwinder in libSystem is fixed to digest new epilog unwinding notes. */

+/* Also ensure that the FSF static libgcc is linked last (unless the user
+   has specified -static-libgcc, in which case it will be linked earlier
+   by the REAL_LIBGCC_SPEC).  */
+
 #undef LIB_SPEC
-#define LIB_SPEC "%{!static:-no_compact_unwind -lSystem}"
+#define LIB_SPEC \
+"%{!static:                                \
+    %:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind)  \
+    -lSystem                                 \
+    %:version-compare(>= 10.6 mmacosx-version-min= -lgcc) }"

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #51 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-04 10:57:39 UTC ---
(In reply to comment #37)
> Let me know when the dust settles and you guys agree on the path forward and I
> will decloak... I've been trying to avoid reading/understanding the issue...

yeah.. we'll get there - just a moderate number of permutations to cover.

In the end there might be a 'style call' required ;)

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #52 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 11:02:02 UTC ---
ain,
    I think the key misassumption you are making is that the internal linker
and dyld behavior for 10.5 is valid under 10.6. Remember that unlike under
Leopard, where /usr/lib/libgcc_s.1.dylib is still a physically unique file...

[MacPro:Leopard HD/usr/lib] howarth% ls -l libgcc*
lrwxr-xr-x  1 howarth  howarth      16 Jul 24  2009 libgcc_s.1.0.dylib ->
libgcc_s.1.dylib
-rw-r--r--  1 howarth  howarth  264016 Oct  6  2007 libgcc_s.1.dylib
-rw-r--r--  1 howarth  howarth   33256 Feb 19  2008 libgcc_s.10.4.dylib
-rw-r--r--  1 howarth  howarth   33620 Feb 19  2008 libgcc_s.10.5.dylib
lrwxr-xr-x  1 howarth  howarth      16 Jul 24  2009 libgcc_s_ppc64.1.dylib ->
libgcc_s.1.dylib
lrwxr-xr-x  1 howarth  howarth      16 Jul 24  2009 libgcc_s_x86_64.1.dylib ->
libgcc_s.1.dylib

under 10.6, it is only a symlink for libSystem itself...

[MacPro:/usr/lib] howarth% ls -l libgcc*
lrwxr-xr-x  1 root  wheel     17 Nov  4 19:37 libgcc_s.1.dylib ->
libSystem.B.dylib
lrwxr-xr-x  1 root  wheel     19 Nov  4 20:32 libgcc_s.10.4.dylib ->
libgcc_s.10.5.dylib
-rwxr-xr-x  1 root  wheel  40668 Apr 23  2010 libgcc_s.10.5.dylib

So under -mmacosx-version-min=10.6, the linker and dyld only have to use the
magic symbols to properly disregard the duplicate symbols in the
libgcc_s.*.dylib symlinks. When these changes were designed, Apple likely
didn't consider that someone would come along with an additional
libgcc_s.1.dylib and start linking that in as well. We need to treat the
linkage of -lgcc_ext.10.5 under -mmacosx-version-min=10.6 as in the same
category as the linkage of -lgcc and wrapper it with -lSystem as well,

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #53 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-04 11:26:14 UTC ---
(In reply to comment #52)
> ain,
>     I think the key misassumption you are making is that the internal linker
> and dyld behavior for 10.5 is valid under 10.6. Remember that unlike under
> Leopard, where /usr/lib/libgcc_s.1.dylib is still a physically unique file...
> 
> [MacPro:Leopard HD/usr/lib] howarth% ls -l libgcc*
> lrwxr-xr-x  1 howarth  howarth      16 Jul 24  2009 libgcc_s.1.0.dylib ->
> libgcc_s.1.dylib
> -rw-r--r--  1 howarth  howarth  264016 Oct  6  2007 libgcc_s.1.dylib
> -rw-r--r--  1 howarth  howarth   33256 Feb 19  2008 libgcc_s.10.4.dylib
> -rw-r--r--  1 howarth  howarth   33620 Feb 19  2008 libgcc_s.10.5.dylib
> lrwxr-xr-x  1 howarth  howarth      16 Jul 24  2009 libgcc_s_ppc64.1.dylib ->
> libgcc_s.1.dylib
> lrwxr-xr-x  1 howarth  howarth      16 Jul 24  2009 libgcc_s_x86_64.1.dylib ->
> libgcc_s.1.dylib
> 
> under 10.6, it is only a symlink for libSystem itself...

No, don't think I'm missing this ... if you read back through the comments, you
will see that I've already made the point ;)

> [MacPro:/usr/lib] howarth% ls -l libgcc*
> lrwxr-xr-x  1 root  wheel     17 Nov  4 19:37 libgcc_s.1.dylib ->
> libSystem.B.dylib
> lrwxr-xr-x  1 root  wheel     19 Nov  4 20:32 libgcc_s.10.4.dylib ->
> libgcc_s.10.5.dylib
> -rwxr-xr-x  1 root  wheel  40668 Apr 23  2010 libgcc_s.10.5.dylib
> 
> So under -mmacosx-version-min=10.6, the linker and dyld only have to use the
> magic symbols to properly disregard the duplicate symbols in the
> libgcc_s.*.dylib symlinks. When these changes were designed, Apple likely
> didn't consider that someone would come along with an additional
> libgcc_s.1.dylib and start linking that in as well. We need to treat the
> linkage of -lgcc_ext.10.5 under -mmacosx-version-min=10.6 as in the same
> category as the linkage of -lgcc and wrapper it with -lSystem as well,

well the 'magic symbols' are AFAICT undocumented.

However, the behaviors of two-level namespace and -flat_namespace are
documented.

Whilst it is quite possible that Apple were not expecting someone to add
libgcc_ext - it is no different than any other case where potential duplicates
are involved.  

Since 'magic symbols' are undocumented and we are speculating, my view is that
they are there so that, when you link -mmacosx-version-min=10.5 on a 10.6 box,
the result contains a reference to /usr/lib/libgcc_s.1.dylib for the Unwinder
symbols (because they do not exist in libSystem before 10.6).

(I suggest that we take any more discussion of magic symbols off-line since we
have no factual basis to decide at the moment)

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #54 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 12:02:18 UTC ---
Test results for proposed patch in Comment 45 at
http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg00416.html.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #55 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 12:31:28 UTC ---
Moved conversation upstream for definitive answer from the Apple linker
developer...

http://lists.apple.com/archives/darwin-dev//2011/Feb/msg00000.html

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #56 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 15:11:29 UTC ---
The following works as a testcase for PR47558

test_main.c
--------------------------
void main (void)
{
extern int unwindcall(void);
int i;
i=unwindcall();
}
--------------------------

test_call.c
---------------------------
int unwindcall (void)
{
static __thread i; 
  i+i; 
  _Unwind_Resume ((void *)0); 
  return i;
}
----------------------------

./dist/bin/gcc -dynamiclib -o libtestcall.dylib -flat_namespace -undefined
suppress -single_module test_call.c
./dist/bin/gcc -o PR47558.exe test_main.c ./libtestcall.dylib

otool -L PR47558.exe
PR47558.exe:
    libtestcall.dylib (compatibility version 0.0.0, current version 0.0.0)
    /Users/howarth/dist/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.1)

./PR47558.exe 
Abort

 gdb ./PR47558.exe 
GNU gdb 6.3.50-20050815 (Apple version gdb-1510) (Wed Sep 22 02:45:02 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries .... done

(gdb) r
Starting program: /Users/howarth/PR47558.exe 
Reading symbols for shared libraries +++. done

Program received signal SIGABRT, Aborted.
0x00007fff87c05616 in __kill ()
(gdb) bt
#0  0x00007fff87c05616 in __kill ()
#1  0x00007fff87ca5cca in abort ()
#2  0x00000001000147a6 in uw_init_context_1 (context=0x7fff5fbfe5d0,
outer_cfa=0x7fff5fbfe800, outer_ra=0x100003f75) at
../../../gcc/libgcc/../gcc/unwind-dw2.c:1265
(gdb)

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #57 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-04 15:16:42 UTC ---
For the testcase in Comment 56 using my proposed patch from Comment 45...

gcc-4 -dynamiclib -o libtestcall.dylib -flat_namespace -undefined suppress
-single_module test_call.c
gcc-4 -o PR47558.exe test_main.c ./libtestcall.dylib

otool -L ./PR47558.exe 
./PR47558.exe:
    libtestcall.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.10)
    /sw/lib/gcc4.6/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)

gdb ./PR47558.exe
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000010
0x00007fff839d3c35 in _Unwind_Resume ()
(gdb) bt
#0  0x00007fff839d3c35 in _Unwind_Resume ()
#1  0x0000000100003f75 in unwindcall ()
#2  0x0000000100000f7b in main ()

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #58 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-05 12:21:51 UTC ---
The response from Nick indicates that the documentation for -flat_namespace and
two-level namespaces is correct and up to date - so we should proceed with a
fix.

>From a general specs point of view, I don't think we should be including
libSystem in REAL_LIBGCC_SPEC, it kinda defeats the object of separating %G and
%L.  If we don't care about this, then let's just set one of those to "" to
avoid future confusion. 

* We also need to watch out for the fact that fortran and java both hijack *lib
to interpose their library lists.

Here is a patch that should achieve the same thing as
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00274.html, but using the
LINK_GCC_C_SEQUENCE_SPEC (essentially a slightly more sophisticated version of
comment #17).

It is probably harmless to insert libSystem before libgcc_s on Darwin 9 - since
there are no unwinder symbols in Darwin 9's libSystem -- however, for the sake
of consistency with other tools, I've wrapped it specifically for Darwin >= 10.

(sometime I'd also like to split -no_compact_unwinder into its own macro - and
provide a user way to switch it off - although it's still needed by default, as
things stand).

In addition to the cases already posted; for fortran, I get a link order of:
 -lgfortran -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5 -lgcc
-lSystem

(incidentally, the presence of the unfiltered -lm in that spec means an
effective additional -lSystem)

and with -mmacosx-version-min=10.5:
 -lgfortran -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_s.10.5
-lgcc_ext.10.5 -lgcc -lSystem 

for java 

-lSystem -lgcc_ext.10.5 -lgcc -lgcj /usr/lib/libiconv.dylib -lz
-allow_stack_execute -lgcc_ext.10.5 -lgcc -lSystem 

and with -mmacosx-version-min=10.5:
-lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -lgcj /usr/lib/libiconv.dylib -lz
-allow_stack_execute -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -lSystem

====

- I can't test the xplor package tho' so Jack might wish to do so.

*** Note that, during looking at this, I discovered that libjava/libltdl has an
acinclude.m4 that uses several obsolete macros, including one that inserts
-flat_namespace in the sequence for undefined symbol handling - on at least
Darwin 9 and 10.  Needs addressing as a separate problem, of course.   A
temporary workaround for that is to set MACOSX_DEPLOYMENT_TARGET before
building java. ***

====

IMO, we still need to fix things such that (a) we don't need to link against
libgcc.a when doing shared linking (b) we change the name of our export lib
(e.g. to libgcc_ext.1.dylib) and only export the symbols we need. 


Index: gcc/config/darwin10.h
===================================================================
--- gcc/config/darwin10.h    (revision 169811)
+++ gcc/config/darwin10.h    (working copy)
@@ -1,5 +1,5 @@
 /* Target definitions for Darwin (Mac OS X) systems.
-   Copyright (C) 2009, 2010 Free Software Foundation, Inc.
+   Copyright (C) 2009, 2010, 2011 Free Software Foundation, Inc.
    Contributed by Jack Howarth <howarth@bromo.med.uc.edu>.

 This file is part of GCC.
@@ -18,8 +18,16 @@ You should have received a copy of the GNU General
 along with GCC; see the file COPYING3.  If not see
 <http://www.gnu.org/licenses/>.  */

+#undef LIB_SPEC
+#define LIB_SPEC "%{!static: -lSystem }"
+
 /* Fix PR41260 by passing -no_compact_unwind on darwin10 and later until
-unwinder in libSystem is fixed to digest new epilog unwinding notes. */
+   unwinder in libSystem is fixed to digest new epilog unwinding notes. */

-#undef LIB_SPEC
-#define LIB_SPEC "%{!static:-no_compact_unwind -lSystem}"
+/* FIXME: Work around PR47558 by linking against libSystem ahead of 
+   libgcc_ext. */
+#undef  LINK_GCC_C_SEQUENCE_SPEC
+#define LINK_GCC_C_SEQUENCE_SPEC \
+"%:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind) \
+   %{!static:%{!static-libgcc: \
+      %:version-compare(>= 10.6 mmacosx-version-min= -lSystem) } } %G %L"

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #59 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-05 18:40:15 UTC ---
I can confirm that the patch in Comment 58 both eliminates the failure in the
reduced test case from Comment 56 as well as the failure in the dipCoup test in
xplor-nih. I am less certain that we want the
current phrasing of the comment...

+/* FIXME: Work around PR47558 by linking against libSystem ahead of 
+   libgcc_ext. */

We should arrive at a consensus on whether symbols which overlap between
libgcc_ext and libSystem should be given priority in libSystem and resolved
there. This patch achieves this and if we agree this should be the case, the
comment should instead read...

+/* Linking libSystem ahead of libgcc_ext prioritizes those overlapping symbols
in libSystem
+    over those from libgcc_ext which re-exposes PR42333. */

This is the correct behavior for the long-run on darwin and we should re-double
our efforts to get
<rdar://problem/7457013>,  ___divdc3 slightly wrong, fixed in Lion.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #60 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-05 18:57:20 UTC ---
(In reply to comment #59)
> I can confirm that the patch in Comment 58 both eliminates the failure in the
> reduced test case from Comment 56 as well as the failure in the dipCoup test in
> xplor-nih. I am less certain that we want the
> current phrasing of the comment...
> 
> +/* FIXME: Work around PR47558 by linking against libSystem ahead of 
> +   libgcc_ext. */

My feeling is that the FIXME should relate to the problem at hand - which is
that our existing _ext design is incompatible with -flat_namespace.  That is
what needs fixing.

> We should arrive at a consensus on whether symbols which overlap between
> libgcc_ext and libSystem should be given priority in libSystem and resolved
> there. This patch achieves this and if we agree this should be the case, the
> comment should instead read...

the way to achieve that is to make a proper 10.6.ver to control which symbols
we wish to export - (but not the subject of this PR).

> +/* Linking libSystem ahead of libgcc_ext prioritizes those overlapping symbols
> in libSystem
> +    over those from libgcc_ext which re-exposes PR42333. */
> 
> This is the correct behavior for the long-run on darwin and we should re-double
> our efforts to get
> <rdar://problem/7457013>,  ___divdc3 slightly wrong, fixed in Lion.

Well, indeed ... highly desirable to have bugs fixed (but that, again, is not
this bug).

However, I'm not going to nail colours to the mast over the wording of the
FIXME - so long as it is not confusing or misleading to some future maintainer
trying to fix the problem ;)

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #61 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-05 19:04:18 UTC ---
Actually the two issues are entirely intertwined. PR47558 was due to not
prioritizing symbols from libSystem over those from libgcc_ext. FYI, I don't
see why getting ___divdc3 fixed in time for Lion should be that difficult.
Since this issue is in the compiler-rt open source project, I'm sure the linux
users of llvm would not be happy to see their math routines degraded.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #62 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-05 19:23:09 UTC ---
> ... FYI, I don't
> see why getting ___divdc3 fixed in time for Lion should be that difficult.

>From the audit trail of PR42333, this is not a bug but a choice of speed over
safety: the safe implementation of the complex division is not more accurate
that the fast/naive implementation when the later works, it just extend the
range for large/small values of the modulus. If you know that you data are in
the safe region, you may prefer the fast case.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #63 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2011-02-07 20:41:54 UTC ---
Author: mrs
Date: Mon Feb  7 20:41:50 2011
New Revision: 169902

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169902
Log:
    PR target/47558
    Add __ieee_divdc3 entry point.
    * config/i386/darwin.h (DECLARE_LIBRARY_RENAMES): Retain ___divdc3
    entry point.
    (SUBTARGET_INIT_BUILTINS): Call darwin_rename_builtins.
    * config/i386/i386.c (TARGET_INIT_LIBFUNCS): Likewise.
    * config/darwin.c (darwin_rename_builtins): Add.
    * config/darwin-protos.h (darwin_rename_builtins): Add.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/darwin-protos.h
    trunk/gcc/config/darwin.c
    trunk/gcc/config/i386/darwin.h
    trunk/gcc/config/i386/i386.c

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #64 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-07 20:52:40 UTC ---
(In reply to comment #63)
> Author: mrs
> Date: Mon Feb  7 20:41:50 2011
> New Revision: 169902
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169902
> Log:
>     PR target/47558
>     Add __ieee_divdc3 entry point.
>     * config/i386/darwin.h (DECLARE_LIBRARY_RENAMES): Retain ___divdc3
>     entry point.
>     (SUBTARGET_INIT_BUILTINS): Call darwin_rename_builtins.
>     * config/i386/i386.c (TARGET_INIT_LIBFUNCS): Likewise.
>     * config/darwin.c (darwin_rename_builtins): Add.
>     * config/darwin-protos.h (darwin_rename_builtins): Add.
> 
> Modified:
>     trunk/gcc/ChangeLog
>     trunk/gcc/config/darwin-protos.h
>     trunk/gcc/config/darwin.c
>     trunk/gcc/config/i386/darwin.h
>     trunk/gcc/config/i386/i386.c

that would mean we could apply comment #58 without regression, if Mike approves
?
(with/without amendment of FIXME text as you wish)

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #65 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-07 20:55:31 UTC ---
>   /* The system ___divdc3 routine in libSystem on darwin10 is not
>     accurate to 1ulp, ours is, so we avoid ever using the system name
>      for this routine and instead install a non-conflicting name that
>      is accurate.

I think this comment in gcc/config/darwin.c and gcc/config/i386/darwin.h is at
best misleading. The problem is not about accuracy, but the range of validity
of the chosen algorithm. In darwin10, it is
tiny<arg(complex_denominator)**2<huge, while in the FSF lib it is
tiny<arg(complex_denominator)<huge. Note that codes relying on this extended
range are likely to generate infinities elsewhere.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #66 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2011-02-07 21:46:12 UTC ---
Author: mrs
Date: Mon Feb  7 21:46:10 2011
New Revision: 169905

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169905
Log:
2011-02-07  Iain Sandoe  <iains@gcc.gnu.org>

    PR target/47558
    * config/darwin10.h (LINK_GCC_C_SEQUENCE_SPEC): Put -lSystem first
    on 10.6 and later to ensure that we always use the unwinder from
    the system.  Only add -no_compact_unwind when tarteting darwin
    10.6 or later.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/darwin10.h

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
                 CC|                            |mrs at gcc dot gnu.org
      Known to work|                            |4.6.0
         Resolution|                            |FIXED

--- Comment #67 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2011-02-07 21:49:16 UTC ---
Fixed, thanks everyone for all your hard work and insight.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[mikestump at comcast dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #68 from Mike Stump <mikestump at comcast dot net> 2011-02-07 22:20:11 UTC ---
So, what you are saying is that the system routine produces an answer that
isn't correct down to the last digit of precision for at least 1 input?

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #69 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-07 22:58:33 UTC ---
> So, what you are saying is that the system routine produces an answer that
> isn't correct down to the last digit of precision for at least 1 input?

I have not looked in detail to the accuracy of the darwin10 or FSF
implementation in their common range of validity. I am pretty sure that they
are about the same, but even if the darwin10 implementation has a maximum error
twice that of the FSF one, I think this not the reason of PR42333 (it would be
solved by some increase of the tolerance for the comparison). The reason being
that the naive, but fast, algorithm (a+ib)/(c+id)=(a+ib)(c-id)/(c*c+d*d) gives
a sound result only if c*c+d*d does not yield 0.0 nor Inf as it does with the
values in gcc.dg/torture/builtin-math-7.c. 

This is why I think the comments should stress the extended range of validity
for the FSF division rather than a hypothetical accuracy.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[mikestump at comcast dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #70 from Mike Stump <mikestump at comcast dot net> 2011-02-08 03:44:09 UTC ---
If you would like to change the comments to clarify the nasty details, I'll
pre-approve it; though, I think it is unnecessary, as that work references this
bug report, and this bug report details it in enough detail...

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

--- Comment #71 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-08 03:58:46 UTC ---
I passed Dominique's observations upstream to the compiler-rt PR for this which
is the important thing.