Darwin-dev

Download

darwin-dev@lists.apple.com

February 2011

10 participants
12 discussions

RE: -mmacosx-version-min=10.6 behavior with additional libgcc_s.1.dylib's
by Jack Howarth 04 Feb '11

04 Feb '11

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mutt/1.5.18 (2008-05-17) 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-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

-mmacosx-version-min=10.6 behavior with additional libgcc_s.1.dylib's
by Jack Howarth 04 Feb '11

04 Feb '11

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mutt/1.5.18 (2008-05-17) Nick, Can you please confirm that the following analysis of the limitations for handling additional physcial copies of libgcc_s.1.dylib by the linker and dyld under -mmacosx-version-min=10.6 is correct? In FSF gcc 4.5, in order to access all of the additional symbols added to the FSF libgcc_s.1.dylib after the symbol set for libgcc_s.10.5.dylib was defined, versioned copies of libgcc_ext.10.4.dylib and libgcc_ext.10.5.dylib were introduced. These were stubs to the FSF libgcc_s.1.dylib which only exported those symbols not present in the matching libgcc_s.10.4.dylib and libgcc_s.10.5.dylib. The linkage order of -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem was used for both -mmacosx-version-min=10.5 and -mmacosx-version-min=10.6. This results in a linkage order (as viewed by 'otool -L') of... /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 625.0.0) /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) In FSF gcc 4.6, in attempt to remove the /usr/lib/libgcc_s.1.dylib linkage for -mmacosx-version-min=10.6, this linkage was changed to just.. -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem so that 'otool -L' shows... /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) However, while testing builds of xplor-nih (which contains shared libs built with -flat_namespace) using FSF gcc 4.6, I discovered that the exception trackback could become broken and would crash out in the FSF libgcc_s.1.dylib's unwinder. Comparing how Apple gcc 4.2.1 and clang produced linkages under -mmacosx-version-min=10.6, I noticed that both precedes -lgcc with -lSystem. However, for FSF gcc 4.6 under -mmacosx-version-min=10.6, using just... -lgcc_ext.10.5 -lSystem -lgcc -no_compact_unwind -lSystem which retains the linkage order (as seen by 'otool -L') of... /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) was insufficient to eliminate these exception traceback failures when using -flat_namespace. Only the linkage... -lSystem -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem which produces the linkage order (as seen by 'otool -L') of... /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) eliminates the exception traceback failures with -flat_namespace. It is my belief that it is an incorrect assumption that, under -mmacosx-version-min=10.6, the stub mechanism alone will prevent the unexported symbols in the /sw/lib/gcc4.6/lib/libgcc_s.1.dylib from being used by the darwin linker. In other words, for -mmacosx-version-min=10.6, any additional copies of libgcc_s.1.dylib have to be treated the same as the -lgcc linkage and must be preceded by a linkage on -lSystem to insure that its symbols are used. The fact that the /usr/lib/libgcc_s.*.dylib files are all symlinks back to libSystem (which contains magic symbols for those in libgcc_s.10.4.dylib and libgcc_s.10.5.dylib), makes me suspect that the stub mechanism of limiting the exported symbols from additional physical copies of libgcc_s.1.dylib is insufficient alone to prevent the unexported symbols in libgcc_ext.10.5.dylib from being used (hence the traceback into FSF gcc's libgcc_s.1.dylib's unwinder) for -mmacosx-version-min=10.6. Can you confirm that this analysis, that either the design of the linker and dylib for -mmacosx-version-min=10.6 doesn't expect an additional physical linkage on another libgcc_s.1.dylib before libSystem.dylib or that this is a bug in the handling of stubs in the case -mmacosx-version-min=10.6, is correct? Thanks in advance for any advice. Jack ps I would also note that only the use of "-lSystem -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem" causes the duplicate symbol for ___divdc3 is gotten from libSystem again and failures in the FSF gcc gcc.dg/torture/builtin-math-7.c re-exposed (<rdar://problem/7457013> ___divdc3 slightly wrong). Iain is resisting the proposed change to the linkage order for -mmacosx-version-min=10.6 because the details of how the magic symbols in libgcc_s.*.dylib operate are undocumented. Any clarifications will be greatly appreciated. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0