-mmacosx-version-min=10.6 behavior with additional libgcc_s.1.dylib's - darwin-dev

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion -mmacosx-version-min=10.6 behavior with additional libgcc_s.1.dylib's
Received-SPF: pass (google.com: manual fallback record for domain of darwin-dev-bounces+darwin-dev-garchive-73044=googlegroups....@lists.apple.com designates 17.254.13.36 as permitted sender) client-ip=17.254.13.36;
Date: Fri, 4 Feb 2011 17:13:11 -0500
From: Jack Howarth <howa...@bromo.med.uc.edu>
To: Nick Kledzik <kled...@apple.com>
Message-ID: <20110204221311.GA29...@bromo.med.uc.edu>
References: <20110204152832.GA27...@bromo.med.uc.edu>
	<EE28639A-22A8-4E93-90D5-205C4A9B8...@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <EE28639A-22A8-4E93-90D5-205C4A9B8...@apple.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: ia...@gcc.gnu.org, darwin-...@lists.apple.com,
	xcode-us...@lists.apple.com, mikest...@comcast.net
Subject: Re: -mmacosx-version-min=10.6 behavior with additional
	libgcc_s.1.dylib's
Precedence: list
Sender: darwin-dev-bounces+darwin-dev-garchive-73044=googlegroups....@lists.apple.com
Errors-To: darwin-dev-bounces+darwin-dev-garchive-73044=googlegroups....@lists.apple.com

On Fri, Feb 04, 2011 at 10:55:36AM -0800, Nick Kledzik wrote:
> Jack,
> 
> Normally, when the linker produces a final linked image, it records which dylib each undefined symbol was found at build time.  Then, at runtime, dyld only looks for those undefined symbols in the specific dylibs recorded.  When a -flat_namespace is used, the linker records "flat lookup" for which dylib the undefinded was found in.  At runtime, dyld will search each loaded image in load order looking for those undefined symbols when referenced from that -flat_namespace image.  
> 
> Given the above, there are two things that can go wrong: 
> 1) There is one over all chronological load order that is used when dyld  searches for a symbol with flat lookup.  The order of dependent libraries only matters if none of the dependent libraries have been already loaded.  That is, you could have flat_namespace dylib A and dylib B.   A links with dylib X and Y in that order while B links with Y and X in that order.  At runtime, X and Y will be loaded in some order and that order defines how both A and B's undefined symbols are found.   You can use DYLD_PRINT_LIBRARIES to see the actual load order of dylibs.  You can use DYLD_PRINT_BINDINGS to see how all references are bound.
> 
> 2) Mixing flat and two-level namespace dylibs can give unexpected results.  Only the flat namespace dylibs can get their undefined symbols bound differently at runtime.  All the other two-level namespace dylibs will continue to use what they recorded at build time.  In the case of unwinding, that means two different unwinders could be in play and since they have different context pointers you can easily hand off an unwind context from one unwinder to another and boom.

Nick,
   What confused me is how the unwinder symbols for FSF libgcc are ever accessed with the following linkage...

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

Since libgcc_ext.10.5.dylib is created as a stub only exporting those symbols from FSF libgcc_s.1.dylib which don't exist
in libgcc_s.10.5.dylib, we believed that the unwinder symbols in FSF libgcc_s.1.dylib would be invisible to the linker
even when -flat_namespace is used. Or are you saying that the -flat_namespace option allows dyld to look past the stub
of libgcc_ext.10.5 directly at all symbols contained in the FSF libgcc_s.1.dylib? If so, what would be the best approach
for linking here? I have suggested we adopt...

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

which flips linkage from...

	/sw/lib/gcc4.5/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)

to

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

This prevents the FSF libgcc unwinder being accidentally accessed under -flat_namespace. It also has the effect
of having any overlapping symbols in libgcc_ext.10.5.dylib and libSystem (like ___divdc3) resolve from libSystem
(hence the failures we then see in gcc.dg/torture/builtin-math-7.c's execution test due to
<rdar://problem/7457013> ___divdc3 slightly wrong).

> 
> What are you trying to accomplish?  Does the libgcc_ext just have extra math stuff?  Or are you trying to force the use of the gcc unwinder as well? If so, is this because of new gcc unwinder functionality?  or just because you want to test the gcc unwinder?

We are trying to make -flat_namespace more bullet-proof so that the FSF unwinder is never accessed
by accident. FYI, xplor-nih is a mix of c, c++ and fortran which upstream builds on darwin entirely from
the FSF gcc compilers. The xplor-nih program's code is stored in a series of shared libraries all built
with -flat_namespace because they are used both from a standalone driver program (not currently linked
with -flat_namespace) as well as from within python and tcl as bundles.
    In FSF gcc 4.5, we linked as...

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

for both -macosx_version_min=10.5 and -macosx_version_min=10.6 so that even under -flat_namespace, the FSF libgcc
unwinder was never accidentally used. My concern is that FSF gcc 4.6 currently only links that way for
-macosx_version_min=10.5 and use...

-lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem

instead for -macosx_version_min=10.6. This worries me on a couple of issues...

1) Since we are not linking -lSystem before -lgcc, don't we risk pulling in symbols like ___enable_execute_stack
from /sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.6.0/4.6.0/libgcc.a under the FSF gcc 4.6 compiler? I would think
that the absence of either the initial -lgcc_s.10.5 or -lSystem linkage would expose the symbols from the -lgcc
linkage?

2) Since -flat_namespace has been long recommended for porting unix software under Mac OS X, the fact that
the current linkage in FSF gcc 4.6 can accidentally invoke the FSF libgcc unwinder if both the shared libs
and executable aren't all compiled with -flat_namespace is a concern. My experience has been that -flat_namespace
(when used) has only been applied to the shared library builds and not the executables.

          Jack

> 
> -Nick
> 
> On Feb 4, 2011, at 7:28 AM, Jack Howarth wrote:
> > Nick,
> >    Appended is a very simple test case that I found for PR47558 that demonstrates
> > the problem and the proposed fix.
> >               Jack
> > 
> > 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)
> > 
> > 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 ()
> > 
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list      (Darwin-...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/darwin-dev-garchive-73044%40googlegroups.com

This email sent to darwin-dev-garchive-73044@googlegroups.com
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
