[PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
Hi all,
ref: http://gcc.gnu.org/ml/gcc/2008-12/msg00107.html, PR32765 and
http://gcc.gnu.org/ml/fortran/2008-12/ msg00118.html
NOTE to gurus: the whole libgcc_eh, libgcc_s.{10.x, 1} thing is
quite hard to understand.
I searched gcc.pdf, gccint.pdf (0 hits) and the list (not much) ...
and google (mostly speculation).
In the end I had to RTSC
If I now understand correctly, the symbols present in updated
versions of libgcc that are not in the "stock" system libgcc on
darwin - need to be mentioned in the stub libraries (ligcc_s.10.
{4,5,...} ). The emutls ones were not present causing linkage
failures that were silently UNSUPPORTING a lot of tests.
It's also possible that key tests might fail on 64bit processors (see
the referenced threads) which could also result in "UNSUPPORTS"
appearing and disappearing sporadically.
"bootstrap-lean" and "make check" on powerpc-apple-darwin8 and i386-
apple-darwin9 (both on 64 bit processors).
this results in:
g+++1 supported
gcc+4 supported
libgomp+126 supported
I'll look at 32bit processor builds during today.
do you think this is the proper solution ?
Iain
===
Index: gcc/config/i386/darwin-libgcc.10.5.ver
===
--- gcc/config/i386/darwin-libgcc.10.5.ver (revision 142592)
+++ gcc/config/i386/darwin-libgcc.10.5.ver (working copy)
@@ -83,3 +83,5 @@
___udivdi3
___udivmoddi4
___umoddi3
+___emutls_get_address
+___emutls_register_common
Index: gcc/config/i386/darwin-libgcc.10.4.ver
===
--- gcc/config/i386/darwin-libgcc.10.4.ver (revision 142592)
+++ gcc/config/i386/darwin-libgcc.10.4.ver (working copy)
@@ -79,3 +79,5 @@
___udivdi3
___udivmoddi4
___umoddi3
+___emutls_get_address
+___emutls_register_common
Index: gcc/config/rs6000/darwin-libgcc.10.5.ver
===
--- gcc/config/rs6000/darwin-libgcc.10.5.ver(revision 142592)
+++ gcc/config/rs6000/darwin-libgcc.10.5.ver(working copy)
@@ -87,3 +87,6 @@
___udivdi3
___udivmoddi4
___umoddi3
+___emutls_get_address
+___emutls_register_common
+
Index: gcc/config/rs6000/darwin-libgcc.10.4.ver
===
--- gcc/config/rs6000/darwin-libgcc.10.4.ver(revision 142592)
+++ gcc/config/rs6000/darwin-libgcc.10.4.ver(working copy)
@@ -74,3 +74,5 @@
___udivdi3
___udivmoddi4
___umoddi3
+___emutls_get_address
+___emutls_register_common
hfoahzjypgfgg
ivuhfbxbaxj http://zsmpeeg.com/
pgdihcgxgzizq
cvyzbetdmzx http://rzjloyu.com/
question on optimizing calls to library functions
Hi all. While looking at PR fortran/22572, I wondered where the difference between the following two programs might be: $> cat matmul.f90 REAL, DIMENSION(1,1), PARAMETER :: a = 1.0, b = 2.0 REAL, DIMENSION(1,1) :: c c = MATMUL(a, b) c = MATMUL(a, b) end $> cat sin.f90 REAL, DIMENSION(1, 1), PARAMETER :: a = 1.0 REAL, DIMENSION(1, 1) :: b, c b = SIN(a) c = SIN(a) end Compiling both with "-Wall -O3 -S -fdump-tree-original -fdump-tree-optimized", one finds that the calls to SIN in sin.f90 have been optimized into nothingness, while MATMUL in matmul.f90 is spelled out twice in the optimized tree dump. The main difference that springs to mind: SIN is built-in, MATMUL is a library function. In gcc/builtin.defs, one finds DEF_LIB_BUILTIN (BUILT_IN_SIN, "sin", BT_FN_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING) with #define ATTR_MATHFN_FPROUNDING (flag_rounding_math ? \ ATTR_PURE_NOTHROW_NOVOPS_LIST : ATTR_CONST_NOTHROW_LIST) Grep'ing the fortran sources, hardly any ATTR_* are used. Would the application of ATTR_MATHFN_FPROUNDING or any other ATTR_* (e.g. ATTR_PURE?) make any difference for the optimizer? If yes, where and how should these attributes be applied to the function symbol? Are these the right questions to ask or am I barking up the wrong tree? Thanks Daniel
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Wed, Dec 10, 2008 at 08:27:50AM +, IainS wrote:
> Hi all,
>
> ref: http://gcc.gnu.org/ml/gcc/2008-12/msg00107.html, PR32765 and
> http://gcc.gnu.org/ml/fortran/2008-12/ msg00118.html
>
> NOTE to gurus: the whole libgcc_eh, libgcc_s.{10.x, 1} thing is quite
> hard to understand.
> I searched gcc.pdf, gccint.pdf (0 hits) and the list (not much) ... and
> google (mostly speculation).
>
> In the end I had to RTSC
>
> If I now understand correctly, the symbols present in updated versions of
> libgcc that are not in the "stock" system libgcc on darwin - need to be
> mentioned in the stub libraries (ligcc_s.10.{4,5,...} ). The emutls ones
> were not present causing linkage failures that were silently UNSUPPORTING
> a lot of tests.
>
> It's also possible that key tests might fail on 64bit processors (see
> the referenced threads) which could also result in "UNSUPPORTS"
> appearing and disappearing sporadically.
>
> "bootstrap-lean" and "make check" on powerpc-apple-darwin8 and i386-
> apple-darwin9 (both on 64 bit processors).
>
> this results in:
> g+++1 supported
> gcc+4 supported
> libgomp+126 supported
>
> I'll [EMAIL PROTECTED] processor builds during today.
>
> do you think this is the proper solution ?
>
> Iain
>
> ===
>
> Index: gcc/config/i386/darwin-libgcc.10.5.ver
> ===
> --- gcc/config/i386/darwin-libgcc.10.5.ver (revision 142592)
> +++ gcc/config/i386/darwin-libgcc.10.5.ver (working copy)
> @@ -83,3 +83,5 @@
> ___udivdi3
> ___udivmoddi4
> ___umoddi3
> +___emutls_get_address
> +___emutls_register_common
> Index: gcc/config/i386/darwin-libgcc.10.4.ver
> ===
> --- gcc/config/i386/darwin-libgcc.10.4.ver (revision 142592)
> +++ gcc/config/i386/darwin-libgcc.10.4.ver (working copy)
> @@ -79,3 +79,5 @@
> ___udivdi3
> ___udivmoddi4
> ___umoddi3
> +___emutls_get_address
> +___emutls_register_common
> Index: gcc/config/rs6000/darwin-libgcc.10.5.ver
> ===
> --- gcc/config/rs6000/darwin-libgcc.10.5.ver(revision 142592)
> +++ gcc/config/rs6000/darwin-libgcc.10.5.ver(working copy)
> @@ -87,3 +87,6 @@
> ___udivdi3
> ___udivmoddi4
> ___umoddi3
> +___emutls_get_address
> +___emutls_register_common
> +
> Index: gcc/config/rs6000/darwin-libgcc.10.4.ver
> ===
> --- gcc/config/rs6000/darwin-libgcc.10.4.ver(revision 142592)
> +++ gcc/config/rs6000/darwin-libgcc.10.4.ver(working copy)
> @@ -74,3 +74,5 @@
> ___udivdi3
> ___udivmoddi4
> ___umoddi3
> +___emutls_get_address
> +___emutls_register_common
>
>
>
Iain,
I am certain that the Darwin developers would reject such a change.
The versioned symbols presented in libgcc_s.10.4.dylib and in
libgcc_s.10.5.dylib are supposed to be fixed upon release of the
that versioned libgcc in the matching OS release. The contents of
those two shared libraries are not supposed to diverge from those
shipped by Apple with its OS releases. I think what you want to do
make sure you are using the FSF libgcc's and not the system ones
while having environmental MACOSX_DEPLOYMENT_TARGET unset. The latter
step will cause the unversioned libgcc to be used with all the newer
symbols specific to the FSF gcc 4.4 release (that are not listed in
the darwin-libgcc.10.4.ver and darwin-libgcc.10.5.ver files).
Jack
ps It might be possible for you to convince Apple to add new symbols
to the upcoming darwin 10.6 versioned libgcc but they will only
likely do that if they support the same emutls feature in their
gcc 4.2.1 compiler.
[lto] Merge tr...@142607
I just committed a merge with [EMAIL PROTECTED] This merge exposed a
streaming bug in constants. The TREE_OVERFLOW bug does not need to be
streamed out, as it is computed during optimization.
Tested on x86_64.
Diego.
2008-12-09 Diego Novillo <[EMAIL PROTECTED]>
Mainline merge @142607.
* configure.ac (ACX_PKGVERSION): Update revision merge string.
* configure: Regenerate.
2008-12-09 Diego Novillo <[EMAIL PROTECTED]>
* lto-tree-tags.def: Move COND_EXPR to TREE_SINGLE_MECHANICAL_TRUE
handler.
* lto-function-in.c (input_expr_operand): Remove special
handler for COND_EXPR.
(input_tree_operand): Likewise.
* lto-tree-flags.def: Do not stream out TREE_OVERFLOW for
INTEGER_CST.
Index: lto-tree-tags.def
===
--- lto-tree-tags.def (revision 142610)
+++ lto-tree-tags.def (working copy)
@@ -67,7 +67,6 @@
MAP_EXPR_TAG(ARRAY_TYPE, LTO_array_type)
MAP_EXPR_TAG(BOOLEAN_TYPE, LTO_boolean_type)
MAP_EXPR_TAG(COMPLEX_TYPE, LTO_complex_type)
- MAP_EXPR_TAG(COND_EXPR, LTO_cond_expr)
MAP_EXPR_TAG(COMPONENT_REF, LTO_component_ref)
MAP_EXPR_TAG(CONST_DECL, LTO_const_decl)
MAP_EXPR_TAG(CONSTRUCTOR, LTO_constructor)
@@ -118,6 +117,7 @@
MAP_EXPR_TAG(COMPLEX_EXPR, LTO_complex_expr)
MAP_EXPR_TAG(COMPOUND_EXPR, LTO_compound_expr)
MAP_EXPR_TAG(COMPOUND_LITERAL_EXPR, LTO_compound_literal_expr)
+ MAP_EXPR_TAG(COND_EXPR, LTO_cond_expr)
MAP_EXPR_TAG(CONJ_EXPR, LTO_conj_expr)
MAP_EXPR_TAG(CONVERT_EXPR, LTO_convert_expr)
MAP_EXPR_TAG(DECL_EXPR, LTO_decl_expr)
Index: lto-function-in.c
===
--- lto-function-in.c (revision 142610)
+++ lto-function-in.c (working copy)
@@ -877,18 +877,6 @@ input_expr_operand (struct lto_input_blo
result = get_label_decl (data_in, ib);
break;
-case COND_EXPR:
- {
- tree op0;
- tree op1;
- tree op2;
- op0 = input_expr_operand (ib, data_in, fn, input_record_start (ib));
- op1 = input_expr_operand (ib, data_in, fn, input_record_start (ib));
- op2 = input_expr_operand (ib, data_in, fn, input_record_start (ib));
- result = build3 (code, type, op0, op1, op2);
- }
- break;
-
case COMPONENT_REF:
{
tree op0;
@@ -3738,18 +3726,6 @@ input_tree_operand (struct lto_input_blo
}
break;
-case COND_EXPR:
- {
- tree op0;
- tree op1;
- tree op2;
- op0 = input_tree_operand (ib, data_in, fn, input_record_start (ib));
- op1 = input_tree_operand (ib, data_in, fn, input_record_start (ib));
- op2 = input_tree_operand (ib, data_in, fn, input_record_start (ib));
- result = build3 (code, type, op0, op1, op2);
- }
- break;
-
case COMPONENT_REF:
{
tree op0;
Index: lto-tree-flags.def
===
--- lto-tree-flags.def (revision 142610)
+++ lto-tree-flags.def (working copy)
@@ -417,7 +417,6 @@
START_EXPR_CASE (INTEGER_CST)
ADD_EXPR_FLAG (static_flag)
- ADD_EXPR_FLAG (public_flag)
END_EXPR_CASE (INTEGER_CST)
START_EXPR_CASE (INTEGER_TYPE)
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On 10 Dec 2008, at 14:43, Jack Howarth wrote: shipped by Apple with its OS releases. I think what you want to do make sure you are using the FSF libgcc's and not the system ones while having environmental MACOSX_DEPLOYMENT_TARGET unset. The latter step will cause the unversioned libgcc to be used with all the newer symbols specific to the FSF gcc 4.4 release (that are not listed in the darwin-libgcc.10.4.ver and darwin-libgcc.10.5.ver files). I have not found a way (MACOSX_DEPLOYMENT_TARGET set or unset) of getting the loader to look at the FSF libgcc_s.1.dylib unless I specifically name it on the command line with -lgcc_s.1 That does work ( as does -lgcc_eh. ) I guess I misunderstood the purpose of libgcc_s10.x as being "all the symbols added since this release" It would help if someone could point me at some clear documentation about what libgcc_eh libgcc_s.1 libgcc_s.10.X *should* contain. other than that, it's a case of returning to some solution which involves a tls.exp... etc. thanks, Iain
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Wed, Dec 10, 2008 at 02:55:11PM +, IainS wrote: > > On 10 Dec 2008, at 14:43, Jack Howarth wrote: > >> shipped by Apple with its OS releases. I think what you want to do >> make sure you are using the FSF libgcc's and not the system ones >> while having environmental MACOSX_DEPLOYMENT_TARGET unset. The latter >> step will cause the unversioned libgcc to be used with all the newer >> symbols specific to the FSF gcc 4.4 release (that are not listed in >> the darwin-libgcc.10.4.ver and darwin-libgcc.10.5.ver files). > > I have not found a way (MACOSX_DEPLOYMENT_TARGET set or unset) of > getting the loader to look at the FSF libgcc_s.1.dylib unless I > specifically name it on the command line with -lgcc_s.1 > > That does work ( as does -lgcc_eh. ) > > I guess I misunderstood the purpose of libgcc_s10.x as being "all the > symbols added since this release" > > It would help if someone could point me at some clear documentation > about what > > libgcc_eh > libgcc_s.1 > libgcc_s.10.X > > *should* contain. > > other than that, it's a case of returning to some solution which > involves a tls.exp... etc. > > thanks, > Iain Iain, Actually, on reflection, I'm not really sure how one gets the complete set of symbols out of libgcc on darwin any more. The patch... http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00475.html would suggest that the compiler now defaults to the libgcc of the system it is running on, so it is unclear what unsetting MAC_OS_X_DEPLOYMENT_TARGET would achieve. Perhaps Geoff can clarify this behavior and explain how the unversioned set of libgcc symbols can be used? Jack
[strict-aliasing] warning message contains compiler-generated symbols
g++-current generates messages which
1) contains compiler generated symbols
2) refers to gcc internal header (stl_tree.h)
[EMAIL PROTECTED] gcc_err]# g++ -Wall -c -O3 test.cpp
test.cpp: In member function 'void
test::bar(std::_List_iterator >&)':
test.cpp:14: warning: dereferencing pointer '__x.13' does break
strict-aliasing rules
/usr/local/gcc_current/lib/gcc/i686-pc-linux-gnu/4.4.0/include/c++/bits/stl_tree.h:530:
note: initialized from here
test.cpp:14: warning: dereferencing pointer '__x.13' does break
strict-aliasing rules
/usr/local/gcc_current/lib/gcc/i686-pc-linux-gnu/4.4.0/include/c++/bits/stl_tree.h:530:
note: initialized from here
[EMAIL PROTECTED] gcc_err]# g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++ :
(reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion
Thread model: posix
gcc version 4.4.0 20081210 (experimental) [trunk revision 142645] (GCC)
[EMAIL PROTECTED] gcc_err]# uname -a
Linux localhost.localdomain 2.6.26.6-49.fc8 #1 SMP Fri Oct 17 15:59:36
EDT 2008 i686 i686 i386 GNU/Linux
[EMAIL PROTECTED] gcc_err]# cat test.cpp
#include
#include
template
class KeyPairPtr
{
public:
typedef typename std::pair< const Key, Info > Pair;
Pair *pair_ptr;
};
template
bool operator <( const KeyPairPtr &left, const
KeyPairPtr &right ) {
return left.pair_ptr < right.pair_ptr;
}
typedef KeyPairPtr key_val;
class test
{
test();
void bar( std::list::iterator &ci );
std::set foo;
};
void test::bar( std::list::iterator &ci )
{
test ctx;
ctx.foo.insert( *ci );
}
Re: [strict-aliasing] warning message contains compiler-generated symbols
On Wed, Dec 10, 2008 at 5:44 PM, Дмитрий Дьяченко <[EMAIL PROTECTED]> wrote: > g++-current generates messages which > 1) contains compiler generated symbols > 2) refers to gcc internal header (stl_tree.h) > > [EMAIL PROTECTED] gcc_err]# g++ -Wall -c -O3 test.cpp > test.cpp: In member function 'void > test::bar(std::_List_iterator >&)': > test.cpp:14: warning: dereferencing pointer '__x.13' does break > strict-aliasing rules > /usr/local/gcc_current/lib/gcc/i686-pc-linux-gnu/4.4.0/include/c++/bits/stl_tree.h:530: > note: initialized from here > test.cpp:14: warning: dereferencing pointer '__x.13' does break > strict-aliasing rules > /usr/local/gcc_current/lib/gcc/i686-pc-linux-gnu/4.4.0/include/c++/bits/stl_tree.h:530: > note: initialized from here First of all, please file a bugreport about this. Second - wrt 1) - what would you like to see? Sth like 'dereferencing pointer expression does break ...'? (we cannot reliably re-construct the original source expression here). For 2), the system header mechanism should have fixed it unless, of course, the whole thing is inlined (and maybe inform () isn't aware of system-headers either). But I think it is useful to know where it comes from rather than just seeing the warning. Richard.
Re: [strict-aliasing] warning message contains compiler-generated symbols
done PR #38477. I only was trying accuratly report. The message was readable but looks unusual. Dmitry 2008/12/10 Richard Guenther <[EMAIL PROTECTED]>: > On Wed, Dec 10, 2008 at 5:44 PM, Дмитрий Дьяченко <[EMAIL PROTECTED]> wrote: >> g++-current generates messages which >> 1) contains compiler generated symbols >> 2) refers to gcc internal header (stl_tree.h) >> >> [EMAIL PROTECTED] gcc_err]# g++ -Wall -c -O3 test.cpp >> test.cpp: In member function 'void >> test::bar(std::_List_iterator >&)': >> test.cpp:14: warning: dereferencing pointer '__x.13' does break >> strict-aliasing rules >> /usr/local/gcc_current/lib/gcc/i686-pc-linux-gnu/4.4.0/include/c++/bits/stl_tree.h:530: >> note: initialized from here >> test.cpp:14: warning: dereferencing pointer '__x.13' does break >> strict-aliasing rules >> /usr/local/gcc_current/lib/gcc/i686-pc-linux-gnu/4.4.0/include/c++/bits/stl_tree.h:530: >> note: initialized from here > > First of all, please file a bugreport about this. Second - wrt 1) - > what would you like > to see? Sth like 'dereferencing pointer expression does break ...'? > (we cannot reliably > re-construct the original source expression here). For 2), the system > header mechanism > should have fixed it unless, of course, the whole thing is inlined > (and maybe inform () > isn't aware of system-headers either). But I think it is useful to > know where it comes > from rather than just seeing the warning. > > Richard. >
Preferring offset loads/stores
Dear all,
I am working on a GCC port and I have a problem with the code
generation for this architecture. Consider this code:
void f (int buff[]) {
buff[0] += 16;
buff[1] += 32;
}
void g (int buff[]) {
buff[0] = 64;
buff[1] = 128;
}
I get this output:
:
ldw r7,0(r8)
addi r7,r7,16
stw r7,0(r8)
addi r7,r8,4
ldw r6,0(r7)
addi r6,r6,32
stw r6,0(r7)
However, I would prefer to use the offsets during loads and stores in
order to get :
:
ldw r7, 0(r8)
addi r7, r7, 16
stw r7, 0(r8)
ldw r7, 4(r8)
addi r7, r7, 32
stw r7, 4(r8)
For the function g, I get:
0020 :
li r7,0x40
stw r7,0(r8)
li r7,0x80
stw r7,4(r8)
which uses the offset for the store.
Does anybody have ideas why there is a difference between the code
generation both functions or where in the GCC code this is performed
or why the compiler behaves differently for both functions would be
greatly appreciated!
Thanks in advance,
Jc
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Dec 10, 2008, at 9:43 AM, Jack Howarth wrote:
If I now understand correctly, the symbols present in updated
versions of
libgcc that are not in the "stock" system libgcc on darwin - need
to be
mentioned in the stub libraries (ligcc_s.10.{4,5,...} ). The
emutls ones
were not present causing linkage failures that were silently
UNSUPPORTING
a lot of tests.
No, those files are meant to describe what was shipped in the past on
darwin as part of darwin. So, changing them isn't quite the right way
to do this. Best to put them in the libgcc.a file and let them link
in statically. Is there some reason why this doesn't work? I can
answer questions and offer advice, feel free to cc me.
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On 10 Dec 2008, at 18:10, Mike Stump wrote:
On Dec 10, 2008, at 9:43 AM, Jack Howarth wrote:
If I now understand correctly, the symbols present in updated
versions of
libgcc that are not in the "stock" system libgcc on darwin - need
to be
mentioned in the stub libraries (ligcc_s.10.{4,5,...} ). The
emutls ones
were not present causing linkage failures that were silently
UNSUPPORTING
a lot of tests.
No, those files are meant to describe what was shipped in the past
on darwin as part of darwin. So, changing them isn't quite the
right way to do this. Best to put them in the libgcc.a file and
let them link in statically. Is there some reason why this doesn't
work? I can answer questions and offer advice, feel free to cc me.
thanks MIke,
the basic issue is that TLS (as used extensively within gomp) is
implemented, at present, as an emulation (emutls).
This is present in libgcc_s.1.dylib and libgcc_eh.a
However, as Jack says, it seems currently very difficult to persuade
gcc to extract symbols from this un-versioned lib (without mentioning
it specifically on the CL)
Whilst this is a possible work-around for getting the test suite to
work, it concerns me that it's quite obscure and prone to being
missed out, forgotten, and/or fragile.
There is an added inconvenience in that darwin8's ld command behaves
differently from darwin9's
the only work-around I've found that gives equal results on d8 and d9
is to specify -lgcc_eh
these approaches seem like temporary hacks .. and I wonder what a
good long-term solution would be?
cheers,
Iain
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Wed, Dec 10, 2008 at 06:23:18PM +, IainS wrote:
>
> On 10 Dec 2008, at 18:10, Mike Stump wrote:
>
>> On Dec 10, 2008, at 9:43 AM, Jack Howarth wrote:
If I now understand correctly, the symbols present in updated
versions of
libgcc that are not in the "stock" system libgcc on darwin - need
to be
mentioned in the stub libraries (ligcc_s.10.{4,5,...} ). The
emutls ones
were not present causing linkage failures that were silently
UNSUPPORTING
a lot of tests.
>>
>> No, those files are meant to describe what was shipped in the past on
>> darwin as part of darwin. So, changing them isn't quite the right way
>> to do this. Best to put them in the libgcc.a file and let them link in
>> statically. Is there some reason why this doesn't work? I can answer
>> questions and offer advice, feel free to cc me.
>
> thanks MIke,
>
> the basic issue is that TLS (as used extensively within gomp) is
> implemented, at present, as an emulation (emutls).
>
> This is present in libgcc_s.1.dylib and libgcc_eh.a
>
> However, as Jack says, it seems currently very difficult to persuade gcc
> to extract symbols from this un-versioned lib (without mentioning it
> specifically on the CL)
>
> Whilst this is a possible work-around for getting the test suite to
> work, it concerns me that it's quite obscure and prone to being missed
> out, forgotten, and/or fragile.
>
> There is an added inconvenience in that darwin8's ld command behaves
> differently from darwin9's
>
> the only work-around I've found that gives equal results on d8 and d9 is
> to specify -lgcc_eh
>
> these approaches seem like temporary hacks .. and I wonder what a good
> long-term solution would be?
>
> cheers,
> Iain
Iain,
I know we have...
if [istarget *-*-darwin*] {
lappend ALWAYS_CFLAGS "additional_flags=-shared-libgcc"
}
in libgomp/testsuite/lib/libgomp.exp. So you have to make sure
that gets overridden if you wan to use --static-libgcc.
This change was discussed here...
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01497.html
Jack
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On 10 Dec 2008, at 19:05, Jack Howarth wrote:
On Wed, Dec 10, 2008 at 06:23:18PM +, IainS wrote:
On 10 Dec 2008, at 18:10, Mike Stump wrote:
On Dec 10, 2008, at 9:43 AM, Jack Howarth wrote:
If I now understand correctly, the symbols present in updated
versions of
libgcc that are not in the "stock" system libgcc on darwin - need
to be
mentioned in the stub libraries (ligcc_s.10.{4,5,...} ). The
emutls ones
were not present causing linkage failures that were silently
UNSUPPORTING
a lot of tests.
No, those files are meant to describe what was shipped in the
past on
darwin as part of darwin. So, changing them isn't quite the
right way
to do this. Best to put them in the libgcc.a file and let them
link in
statically. Is there some reason why this doesn't work? I can
answer
questions and offer advice, feel free to cc me.
thanks MIke,
the basic issue is that TLS (as used extensively within gomp) is
implemented, at present, as an emulation (emutls).
This is present in libgcc_s.1.dylib and libgcc_eh.a
However, as Jack says, it seems currently very difficult to
persuade gcc
to extract symbols from this un-versioned lib (without mentioning it
specifically on the CL)
Whilst this is a possible work-around for getting the test suite to
work, it concerns me that it's quite obscure and prone to being
missed
out, forgotten, and/or fragile.
There is an added inconvenience in that darwin8's ld command behaves
differently from darwin9's
the only work-around I've found that gives equal results on d8 and
d9 is
to specify -lgcc_eh
these approaches seem like temporary hacks .. and I wonder what a
good
long-term solution would be?
cheers,
Iain
Iain,
I know we have...
if [istarget *-*-darwin*] {
lappend ALWAYS_CFLAGS "additional_flags=-shared-libgcc"
}
in libgomp/testsuite/lib/libgomp.exp. So you have to make sure
that gets overridden if you wan to use --static-libgcc.
This change was discussed here...
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01497.html
Jack
Yes, that's understood. However:
--static-libgcc does not work (any more, if it used to) with D8
(unless you install the compiler before make check).
libgomp.1.dylib => libgcc_s.1.dylib and D8's ld command objects.
I already commented that if you do --static-libgcc with D9 then
libgomp -> libgcc_s.1
mainline -> statically linked with libgcc.a
this doesn't seem a good idea.
using libgcc_eh.a minimises this (in the case of the libgomp tests)
because the only symbols that happen to be sourced are the __emutls
ones.
However, that's not a general case.
=-
I suppose I'd expected the current *compiler* symbols to take
precedence over the system ones (unless I specifically demand that
the linked binary is usable w/out delivering the updated runtimes).
For any of this to be useful to an end-user we must accept that the
libgfortran/libgomp .. etc etc. runtimes would have to be installed
on the end-user's system (since they are not currently part of any D8/
D9 system).
`pologies, if I'm being slow... there is a large learning curve here...
cheers,
Iain
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Wed, Dec 10, 2008 at 07:39:35PM +, IainS wrote:
>
> On 10 Dec 2008, at 19:05, Jack Howarth wrote:
>
>> On Wed, Dec 10, 2008 at 06:23:18PM +, IainS wrote:
>>>
>>> On 10 Dec 2008, at 18:10, Mike Stump wrote:
>>>
On Dec 10, 2008, at 9:43 AM, Jack Howarth wrote:
>> If I now understand correctly, the symbols present in updated
>> versions of
>> libgcc that are not in the "stock" system libgcc on darwin - need
>> to be
>> mentioned in the stub libraries (ligcc_s.10.{4,5,...} ). The
>> emutls ones
>> were not present causing linkage failures that were silently
>> UNSUPPORTING
>> a lot of tests.
No, those files are meant to describe what was shipped in the past
on
darwin as part of darwin. So, changing them isn't quite the right
way
to do this. Best to put them in the libgcc.a file and let them
link in
statically. Is there some reason why this doesn't work? I can
answer
questions and offer advice, feel free to cc me.
>>>
>>> thanks MIke,
>>>
>>> the basic issue is that TLS (as used extensively within gomp) is
>>> implemented, at present, as an emulation (emutls).
>>>
>>> This is present in libgcc_s.1.dylib and libgcc_eh.a
>>>
>>> However, as Jack says, it seems currently very difficult to persuade
>>> gcc
>>> to extract symbols from this un-versioned lib (without mentioning it
>>> specifically on the CL)
>>>
>>> Whilst this is a possible work-around for getting the test suite to
>>> work, it concerns me that it's quite obscure and prone to being
>>> missed
>>> out, forgotten, and/or fragile.
>>>
>>> There is an added inconvenience in that darwin8's ld command behaves
>>> differently from darwin9's
>>>
>>> the only work-around I've found that gives equal results on d8 and
>>> d9 is
>>> to specify -lgcc_eh
>>>
>>> these approaches seem like temporary hacks .. and I wonder what a
>>> good
>>> long-term solution would be?
>>>
>>> cheers,
>>> Iain
>>
>> Iain,
>>I know we have...
>>
>> if [istarget *-*-darwin*] {
>> lappend ALWAYS_CFLAGS "additional_flags=-shared-libgcc"
>> }
>>
>> in libgomp/testsuite/lib/libgomp.exp. So you have to make sure
>> that gets overridden if you wan to use --static-libgcc.
>> This change was discussed here...
>>
>> http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01497.html
>>
>> Jack
>
> Yes, that's understood. However:
>
> --static-libgcc does not work (any more, if it used to) with D8 (unless
> you install the compiler before make check).
>
> libgomp.1.dylib => libgcc_s.1.dylib and D8's ld command objects.
>
> I already commented that if you do --static-libgcc with D9 then
>
> libgomp -> libgcc_s.1
> mainline -> statically linked with libgcc.a
>
> this doesn't seem a good idea.
>
> using libgcc_eh.a minimises this (in the case of the libgomp tests)
> because the only symbols that happen to be sourced are the __emutls
> ones.
>
> However, that's not a general case.
>
> =-
>
> I suppose I'd expected the current *compiler* symbols to take precedence
> over the system ones (unless I specifically demand that the linked binary
> is usable w/out delivering the updated runtimes).
>
> For any of this to be useful to an end-user we must accept that the
> libgfortran/libgomp .. etc etc. runtimes would have to be installed on
> the end-user's system (since they are not currently part of any D8/D9
> system).
>
> `pologies, if I'm being slow... there is a large learning curve here...
>
> cheers,
> Iain
Iain,
Since your objections are entirely related to the testsuite when
FSF has not been installed, perhaps it would be more productive to see
if the testsuite in libgomp can be reworked to handle darwin when
gcc is uninstalled.
Jack
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Dec 10, 2008, at 10:23 AM, IainS wrote:
I wonder what a good long-term solution would be?
You can try something like:
#define
REAL_LIBGCC_SPEC \
"%{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 mmacosx-version-min= -lgcc_s.
10.5)\
-lgcc_eh -
lgcc; \
:%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.
10.4) \
%:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.
10.5)\
-lgcc_eh -lgcc}"
in config/darwin.h. I'm thinking that most of the symbols should then
come from the shared libraries as applicable, and newer routines in
gcc_eh (like the thread emulation package, which has nothing to do
with eh, right?) can be found. Another possibility, would be to split
out the tls emulation package from gcc_eh. We avoid gcc_eh, so as to
not pull in any routines that would shear with those in the system
libgcc_s.
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On 10 Dec 2008, at 19:46, Jack Howarth wrote:
Since your objections are entirely related to the testsuite when
FSF has not been installed,
hm. I'm not entirely sure that's the whole case... although that was
the trigger for this chain of investigation.
I'm also wondering what instructions one gives to the developer
about how code using TLS should be built/delivered.
perhaps it would be more productive to see
if the testsuite in libgomp can be reworked to handle darwin when
gcc is uninstalled.
the patch below gives the same result on D9 (checking is still
running on D8) as the change I posted earlier (for libgomp only)
obviously a similar thing needs to be done other places where TLS is
used.
Index: libgomp/testsuite/lib/libgomp.exp
===
--- libgomp/testsuite/lib/libgomp.exp (revision 142648)
+++ libgomp/testsuite/lib/libgomp.exp (working copy)
@@ -113,9 +113,15 @@
if { "$mldir" == "." } {
continue
}
- if { [llength [glob -nocomplain ${gccdir}/${mldir}/
libgcc_s*.so.*]] >= 1 } {
- append always_ld_library_path ":${gccdir}/${mldir}"
- }
+ if [istarget *-*-darwin*] {
+ if { [llength [glob -nocomplain ${gccdir}/${mldir}/
libgcc_s*.dylib]] >= 1 } {
+ append always_ld_library_path
":${gccdir}/${mldir}"
+ }
+ } else {
+ if { [llength [glob -nocomplain ${gccdir}/${mldir}/
libgcc_s*.so.*]] >= 1 } {
+ append always_ld_library_path
":${gccdir}/${mldir}"
+ }
+ }
}
}
}
@@ -127,7 +133,6 @@
lappend ALWAYS_CFLAGS "ldflags=-L${blddir}/.libs"
}
lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/.."
-lappend ALWAYS_CFLAGS "ldflags=-lgomp"
# We use atomic operations in the testcases to validate results.
if { ([istarget i?86-*-*] || [istarget x86_64-*-*])
@@ -135,10 +140,6 @@
lappend ALWAYS_CFLAGS "additional_flags=-march=i486"
}
-if [istarget *-*-darwin*] {
- lappend ALWAYS_CFLAGS "additional_flags=-shared-libgcc"
-}
-
if [istarget sparc*-*-*] {
lappend ALWAYS_CFLAGS "additional_flags=-mcpu=v9"
}
@@ -153,6 +154,15 @@
# And, gee, turn on OpenMP.
lappend ALWAYS_CFLAGS "additional_flags=-fopenmp"
+
+if [istarget *-*-darwin*] {
+ #lappend ALWAYS_CFLAGS "additional_flags=-shared-libgcc"
+ # we need to use the unversioned libgcc to pick up the TLS emulation
+ lappend ALWAYS_CFLAGS "additional_flags=-lgcc_s.1"
+} else {
+ # it's not clear who needs this ... -fopenmp should do this no?
+ lappend ALWAYS_CFLAGS "ldflags=-lgomp"
+ }
}
#
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On 10 Dec 2008, at 19:58, Mike Stump wrote: emulation package, which has nothing to do with eh, right?) that thought had crossed my mind a few times ;-) can be found. Another possibility, would be to split out the tls emulation package from gcc_eh. We avoid gcc_eh, so as to not pull in any routines that would shear with those in the system libgcc_s. I wondered about making all this specific with a "-femulate-tls" and the associated SPEC. However, I'm way out of my depth here - in terms of appreciating the implications of such a thought. Iain
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
FWIW clearly, this *can* be done .. the open question is whether it *should* be done :-) On 10 Dec 2008, at 19:59, IainS wrote: perhaps it would be more productive to see if the testsuite in libgomp can be reworked to handle darwin when gcc is uninstalled. the patch below gives the same result on D9 (checking is still running on D8) finished... http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01022.html http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01023.html Iain
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote: On Wed, Dec 10, 2008 at 02:55:11PM +, IainS wrote: On 10 Dec 2008, at 14:43, Jack Howarth wrote: shipped by Apple with its OS releases. I think what you want to do make sure you are using the FSF libgcc's and not the system ones while having environmental MACOSX_DEPLOYMENT_TARGET unset. The latter step will cause the unversioned libgcc to be used with all the newer symbols specific to the FSF gcc 4.4 release (that are not listed in the darwin-libgcc.10.4.ver and darwin-libgcc.10.5.ver files). I have not found a way (MACOSX_DEPLOYMENT_TARGET set or unset) of getting the loader to look at the FSF libgcc_s.1.dylib unless I specifically name it on the command line with -lgcc_s.1 That does work ( as does -lgcc_eh. ) I guess I misunderstood the purpose of libgcc_s10.x as being "all the symbols added since this release" It would help if someone could point me at some clear documentation about what libgcc_eh libgcc_s.1 libgcc_s.10.X *should* contain. other than that, it's a case of returning to some solution which involves a tls.exp... etc. thanks, Iain Iain, Actually, on reflection, I'm not really sure how one gets the complete set of symbols out of libgcc on darwin any more. The patch... http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00475.html would suggest that the compiler now defaults to the libgcc of the system it is running on, so it is unclear what unsetting MAC_OS_X_DEPLOYMENT_TARGET would achieve. Perhaps Geoff can clarify this behavior and explain how the unversioned set of libgcc symbols can be used? All this is documented in darwin.h: /* Support -mmacosx-version-min by supplying different (stub) libgcc_s.dylib libraries to link against, and by not linking against libgcc_s on earlier-than-10.3.9. Note that by default, -lgcc_eh is not linked against! This is because in a future version of Darwin the EH frame information may be in a new format, or the fallback routine might be changed; if you want to explicitly link against the static version of those routines, because you know you don't need to unwind through system libraries, you need to explicitly say -static-libgcc. If it is linked against, it has to be before -lgcc, because it may need symbols from -lgcc. */ libgcc_s.10.x.dylib are stub libraries that list the symbols that were shipped in libgcc_s.1.dylib in Mac OS version 10.x. The compiler links with '-lgcc_s.10.x -lgcc' and so any particular routine comes either from libgcc_s.10.x.dylib, if it's there, or from libgcc.a, if it wasn't present on that system. The particular 'x' is based on the -mmacosx-version-min flag. A long time ago the MACOSX_DEPLOYMENT_TARGET environment variable was used for this but it should not be used today, because environment variables are bad. To use the 'unversioned set' implies that you're compiling for a version of Mac OS that Apple has not yet created and most likely will never exist. This is not useful. One way to get extra runtime support is put routines in libgcc.a which can be statically linked into executables if they aren't present in the system. The routines in libgcc_eh.a are routines which should normally never be statically linked into executables, because they won't work if you do that; they must be in the system. If you need a routine that's in libgcc_eh.a, and it's not in the system, you're out of luck; you can't use it. You'd need to rewrite it so it can handle being linked into multiple executables, or you'd need to create a new shared library, put the routine in it, and ship that shared library with every executable you create. smime.p7s Description: S/MIME cryptographic signature
gcc-4.2-20081210 is now available
Snapshot gcc-4.2-20081210 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20081210/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 142662 You'll find: gcc-4.2-20081210.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20081210.tar.bz2 C front end and core compiler gcc-ada-4.2-20081210.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20081210.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20081210.tar.bz2 C++ front end and runtime gcc-java-4.2-20081210.tar.bz2 Java front end and runtime gcc-objc-4.2-20081210.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20081210.tar.bz2The GCC testsuite Diffs from 4.2-20081203 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
Thanks Geoff, that's v. useful doc. On 10 Dec 2008, at 22:36, Geoff Keating wrote: On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote: On Wed, Dec 10, 2008 at 02:55:11PM +, IainS wrote: To use the 'unversioned set' implies that you're compiling for a version of Mac OS that Apple has not yet created and most likely will never exist. This is not useful. One way to get extra runtime support is put routines in libgcc.a which can be statically linked into executables if they aren't present in the system. if one did -lgcc_s.10.x -lgcc_s.1 would that break it? ... should it not pick up only the unresolved symbols from s.1 ( you would also have to be prepared to install libgcc_s.1 in a suitable place). The routines in libgcc_eh.a are routines which should normally never be statically linked into executables, because they won't work if you do that; they must be in the system. If you need a routine that's in libgcc_eh.a, and it's not in the system, you're out of luck; you can't use it. You'd need to rewrite it so it can handle being linked into multiple executables, or you'd need to create a new shared library, put the routine in it, and ship that shared library with every executable you create. OK, we've got quite a bit of work to do then, all the runtime libs (gfortran, stdc++v3, gomp, ffi, java) link on libgcc_s.1.dylib and, if we want to be able to use gomp, then I we need to find a way to provide emutls. This, obviously, should not be by linking with gcc_eh (since people would want the current system-provided exception mechanism to continue to work, I imagine). thanks, for the explanations - it's been an educational day! Iain
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Wed, Dec 10, 2008 at 02:36:22PM -0800, Geoff Keating wrote: > > On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote: > >> On Wed, Dec 10, 2008 at 02:55:11PM +, IainS wrote: >>> >>> On 10 Dec 2008, at 14:43, Jack Howarth wrote: >>> shipped by Apple with its OS releases. I think what you want to do make sure you are using the FSF libgcc's and not the system ones while having environmental MACOSX_DEPLOYMENT_TARGET unset. The latter step will cause the unversioned libgcc to be used with all the newer symbols specific to the FSF gcc 4.4 release (that are not listed in the darwin-libgcc.10.4.ver and darwin-libgcc.10.5.ver files). >>> >>> I have not found a way (MACOSX_DEPLOYMENT_TARGET set or unset) of >>> getting the loader to look at the FSF libgcc_s.1.dylib unless I >>> specifically name it on the command line with -lgcc_s.1 >>> >>> That does work ( as does -lgcc_eh. ) >>> >>> I guess I misunderstood the purpose of libgcc_s10.x as being "all the >>> symbols added since this release" >>> >>> It would help if someone could point me at some clear documentation >>> about what >>> >>> libgcc_eh >>> libgcc_s.1 >>> libgcc_s.10.X >>> >>> *should* contain. >>> >>> other than that, it's a case of returning to some solution which >>> involves a tls.exp... etc. >>> >>> thanks, >>> Iain >> >> Iain, >> Actually, on reflection, I'm not really sure how one gets the >> complete set of symbols out of libgcc on darwin any more. The patch... >> >> http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00475.html >> >> would suggest that the compiler now defaults to the libgcc of >> the system it is running on, so it is unclear what unsetting >> MAC_OS_X_DEPLOYMENT_TARGET would achieve. Perhaps Geoff can >> clarify this behavior and explain how the unversioned set >> of libgcc symbols can be used? > > > All this is documented in darwin.h: > > /* Support -mmacosx-version-min by supplying different (stub) > libgcc_s.dylib >libraries to link against, and by not linking against libgcc_s on >earlier-than-10.3.9. > >Note that by default, -lgcc_eh is not linked against! This is >because in a future version of Darwin the EH frame information may >be in a new format, or the fallback routine might be changed; if >you want to explicitly link against the static version of those >routines, because you know you don't need to unwind through system >libraries, you need to explicitly say -static-libgcc. > >If it is linked against, it has to be before -lgcc, because it may >need symbols from -lgcc. */ > > libgcc_s.10.x.dylib are stub libraries that list the symbols that were > shipped in libgcc_s.1.dylib in Mac OS version 10.x. The compiler links > with '-lgcc_s.10.x -lgcc' and so any particular routine comes either from > libgcc_s.10.x.dylib, if it's there, or from libgcc.a, if it wasn't > present on that system. > > The particular 'x' is based on the -mmacosx-version-min flag. A long > time ago the MACOSX_DEPLOYMENT_TARGET environment variable was used for > this but it should not be used today, because environment variables are > bad. > > To use the 'unversioned set' implies that you're compiling for a version > of Mac OS that Apple has not yet created and most likely will never > exist. This is not useful. > > One way to get extra runtime support is put routines in libgcc.a which > can be statically linked into executables if they aren't present in the > system. > > The routines in libgcc_eh.a are routines which should normally never be > statically linked into executables, because they won't work if you do > that; they must be in the system. If you need a routine that's in > libgcc_eh.a, and it's not in the system, you're out of luck; you can't > use it. You'd need to rewrite it so it can handle being linked into > multiple executables, or you'd need to create a new shared library, put > the routine in it, and ship that shared library with every executable you > create. > Geoff, I am confused. Assuming one builds FSF gcc configured with --enable-threads, shouldn't that create a libgcc.a for FSF gcc containing the ___emutls_get_address and ___emutls_get_address symbols? If so, shouldn't those be drawn in through the normal '-lgcc_s.10.x -lgcc' linkage of the FSF gcc compilers? I am wondering if Iain is short-circuiting with his configuration settings... configure flags: --prefix=/Volumes/ScratchCS/gcc-440-install -- target=i386-apple-darwin9.5.0 --enable-languages=c,c+ +,fortran,objc,obj-c++ --enable-version-specific-runtime-libs -- enable-__cxa_atexit --enable-threads --enable-checking=release -- disable-nls --program-suffix=-4.4.0 Jack ps Why doesn't the darwin build default to enable threads?
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Dec 10, 2008, at 3:24 PM, IainS wrote: Thanks Geoff, that's v. useful doc. On 10 Dec 2008, at 22:36, Geoff Keating wrote: On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote: On Wed, Dec 10, 2008 at 02:55:11PM +, IainS wrote: To use the 'unversioned set' implies that you're compiling for a version of Mac OS that Apple has not yet created and most likely will never exist. This is not useful. One way to get extra runtime support is put routines in libgcc.a which can be statically linked into executables if they aren't present in the system. if one did -lgcc_s.10.x -lgcc_s.1 would that break it? ... should it not pick up only the unresolved symbols from s.1 ( you would also have to be prepared to install libgcc_s.1 in a suitable place). The second part here is the tricky part. I would not recommend installing your libgcc_s.1.dylib in /usr/lib, or anywhere else really, since you don't know that it'll be compatible with the system one. The routines in libgcc_eh.a are routines which should normally never be statically linked into executables, because they won't work if you do that; they must be in the system. If you need a routine that's in libgcc_eh.a, and it's not in the system, you're out of luck; you can't use it. You'd need to rewrite it so it can handle being linked into multiple executables, or you'd need to create a new shared library, put the routine in it, and ship that shared library with every executable you create. OK, we've got quite a bit of work to do then, all the runtime libs (gfortran, stdc++v3, gomp, ffi, java) link on libgcc_s.1.dylib That's normal, every program and shared library on Darwin does that. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Wed, Dec 10, 2008 at 04:13:45PM -0800, Geoff Keating wrote: > > On Dec 10, 2008, at 3:24 PM, IainS wrote: > >> Thanks Geoff, >> that's v. useful doc. >> >> On 10 Dec 2008, at 22:36, Geoff Keating wrote: >> >>> >>> On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote: >>> >>>> On Wed, Dec 10, 2008 at 02:55:11PM +, IainS wrote: >> >> >> >>> To use the 'unversioned set' implies that you're compiling for a >>> version of Mac OS that Apple has not yet created and most likely >>> will never exist. This is not useful. >>> >>> One way to get extra runtime support is put routines in libgcc.a >>> which can be statically linked into executables if they aren't >>> present in the system. >> >> >> if one did -lgcc_s.10.x -lgcc_s.1 would that break it? >> ... should it not pick up only the unresolved symbols from s.1 >> >> ( you would also have to be prepared to install libgcc_s.1 in a >> suitable place). > > The second part here is the tricky part. I would not recommend > installing your libgcc_s.1.dylib in /usr/lib, or anywhere else really, > since you don't know that it'll be compatible with the system one. > >>> The routines in libgcc_eh.a are routines which should normally never >>> be statically linked into executables, because they won't work if you >>> do that; they must be in the system. If you need a routine that's in >>> libgcc_eh.a, and it's not in the system, you're out of luck; you >>> can't use it. You'd need to rewrite it so it can handle being linked >>> into multiple executables, or you'd need to create a new shared >>> library, put the routine in it, and ship that shared library with >>> every executable you create. >> >> OK, we've got quite a bit of work to do then, all the runtime libs >> (gfortran, stdc++v3, gomp, ffi, java) link on libgcc_s.1.dylib > > That's normal, every program and shared library on Darwin does that. > Geoff, What I do for the FSF gcc packaging in fink is create a main gcc4X package and gcc4X-shlibs split-off package. The FSF gcc compilers are all installed within /sw/lib/gcc4.X. This works well since fink packages have build and install dependencies so that I have conflict gcc43 and gcc44 (which contain the compilers and headers) and allow the gcc43-shlibs and gcc44-shlibs packages to co-exist so that anything built with an earlier gcc4X package can keep running. I am confused about the issue with emutls. Check out PR35677. I am seeing... nm crayptr2.exe | grep emut 1cd0 t ___emutls_get_address 1c90 t ___emutls_register_common 2014 d ___emutls_v.ip.1499 1f10 t _emutls_destroy 1ed0 t _emutls_init 2090 b _emutls_key 2040 d _emutls_mutex 2094 b _emutls_size ...built using FSF gcc configured with... Using built-in specs. Target: i686-apple-darwin9 Configured with: ../gcc-4.4-20081209/configure --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-arch=nocona --with-tune=generic --build=i686-apple-darwin9 --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.4.0 20081210 (experimental) (GCC) I assume this implies that the emutls symbols should be accessible with the correct linkage. Odd. Jack
Eurorest - Ajándék az ügyfeleinknek!
Ezt a meghívót kizárólag azok kapják, akik korábban részt vettek Eurorest Akcióban. -- Tisztelt Hölgyeim és Uraim! Az a bizalom, amivel megtiszteltek minket, amikor első alkalommal csatlakoztak az Eurorest Akcióhoz, lehetővé tette számunkra, hogy egy, csak az Eurorest kiválasztott Ügyfeleinek szóló, speciális ajánlatot dolgozzunk ki. Az ajánlat weblapja kizárólag az alábbi speciális linken érhető el: http://eurorest.org/?id=08&lng=hu&zn=31313&pr=E22WR Már több, mint 500.000 magyar és más nemzetiségű személy vette igénybe az olcsó pihenés lehetőségét neves európai hotelekben. Közülük néhányukat ingyenes Eurorest hotelcsekkel lepjük meg! Ha ismét részt vesznek az Eurorest Akciójában, és megtérítik az Eurorest hotelcsekk kibocsátásának és postázásának költségeit, kapnak egy másik csekket ingyen. Arról is örömmel tudunk beszámolni, hogy sikerült az Önök esetében a fizetendő promóciós díjat 4770 Ft összegen tartanunk, annak ellenére, hogy az Eurorest Akció összes költsége emelkedett. És ezért két csekket kapnak! Ahhoz, hogy élhessenek a promócióval, és két Eurorest hotelcsekket kaphassanak úgy, hogy csak az egyiknek a kibocsátási költségeit térítik meg, kérjük írják be a promóciós kódjukat az alábbi linkre kattintva: http://eurorest.org/?id=08&lng=hu&zn=31313&pr=E22WR Egyedi promóciós kód: E22WR Figyelem: ha a fenti link nem működik, akkor kérjük kattintsanak a következő linkre: http://eurorest.org/?id=08&lng=hu&zn=31313 és írják be az egyéni promóciós kódjukat az űrlap megfelelő mezőjébe. Meg vagyunk győződve róla, hogy az általunk ajánlott ajándék lehetővé teszi Önöknek, hogy ismét felejthetetlen pillanatokat töltsenek az 1000 hotel egyikében. Emlékeztetünk, hogy a csekk érvényességi ideje 12 hónap. Önöktől függ, hogy már a közeljövőben, a téli szünet alatt felhasználják a csekkeket, vagy megvárják a melegebb napokat. Önök saját maguk dönthetik el, hogy az ingyenes Eurorest hotelcsekket kettesben használják fel, egy következő utazás alkalmával, vagy ezzel az előnnyel megajándékoznak Önökhöz közelálló személyeket. A közelgő ünnep kedvez az ilyen típusú gesztusnak, így az Eurorest hotelcsekk kitűnő ajándék lehet barátoknak vagy hozzátartozóknak. Kérjük, kattintsanak most: http://eurorest.org/?id=08&lng=hu&zn=31313&pr=E22WR Arról is szeretnénk tájékoztatni Önöket, hogy az ajánlatunk csak addig érvényes, amíg az ingyenes Eurorest hotelcsekkek el nem fogynak. Újabb felejthetetlen pillanatokat kívánunk az Eurorest hotelcsekkel történő üdülés során! Az Eurorest csapata.
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Wed, Dec 10, 2008 at 11:24:28PM +, IainS wrote: > Thanks Geoff, > that's v. useful doc. > > On 10 Dec 2008, at 22:36, Geoff Keating wrote: > >> >> On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote: >> >>> On Wed, Dec 10, 2008 at 02:55:11PM +, IainS wrote: > > > >> To use the 'unversioned set' implies that you're compiling for a >> version of Mac OS that Apple has not yet created and most likely will >> never exist. This is not useful. >> >> One way to get extra runtime support is put routines in libgcc.a which >> can be statically linked into executables if they aren't present in the >> system. > > > if one did -lgcc_s.10.x -lgcc_s.1 would that break it? > ... should it not pick up only the unresolved symbols from s.1 > > ( you would also have to be prepared to install libgcc_s.1 in a > suitable place). > >> >> The routines in libgcc_eh.a are routines which should normally never be >> statically linked into executables, because they won't work if you do >> that; they must be in the system. If you need a routine that's in >> libgcc_eh.a, and it's not in the system, you're out of luck; you can't >> use it. You'd need to rewrite it so it can handle being linked into >> multiple executables, or you'd need to create a new shared library, put >> the routine in it, and ship that shared library with every executable >> you create. > > OK, we've got quite a bit of work to do then, all the runtime libs > (gfortran, stdc++v3, gomp, ffi, java) link on libgcc_s.1.dylib > > and, if we want to be able to use gomp, then I we need to find a way to > provide emutls. > > This, obviously, should not be by linking with gcc_eh (since people > would want the current system-provided exception mechanism to continue to > work, I imagine). > > thanks, for the explanations - it's been an educational day! > > Iain Iain, I think the problem is that we are forcing --shared-libgcc on those testcases that are coming up as UNSUPPORTED. If I recall correctly the --shared-libgcc was added to resolve problems where the libgomp testsuite harness wasn't linking with the g++... http://gcc.gnu.org/ml/gcc/2007-03/msg00479.html http://gcc.gnu.org/ml/gcc/2007-03/msg00485.html http://gcc.gnu.org/ml/gcc/2007-03/msg00495.html http://gcc.gnu.org/ml/gcc/2007-03/msg00532.html The correct fix for gcc 4.5 would be to backout the use of -shared-libgcc from the libgomp testsuite on darwin and fix the test harness to use g++ when appropriate. Jack ps I would also note that you shouldn't need... --enable-version-specific-runtime-libs -- enable-__cxa_atexit --enable-threads -- disable-nls I only use... configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-arch=nocona --with-tune=generic --build=i686-apple-darwin9 --host=i686-apple-darwin9 --target=i686-apple-darwin9 and this links in the emutls symbols fine via -static-libgcc. Look at PR35677. The libgomp.fortran/crayptr2.f90 on darwin shows... nm crayptr2.exe | grep emut 1cd0 t ___emutls_get_address 1c90 t ___emutls_register_common 2014 d ___emutls_v.ip.1499 1f10 t _emutls_destroy 1ed0 t _emutls_init 2090 b _emutls_key 2040 d _emutls_mutex 2094 b _emutls_size but is linked with -static-libgcc.
Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib
On Dec 10, 2008, at 7:03 PM, Jack Howarth wrote: I am confused. Assuming one builds FSF gcc configured with --enable-threads, shouldn't that create a libgcc.a for FSF gcc containing the ___emutls_get_address and ___emutls_get_address symbols? No, the people that wrote ___emutls_get_address decided to put it in gcc_eh, instead of libgcc.a. Sorry. Another fix would be to move it into libgcc.a, but I don't know if that is possible. Why doesn't the darwin build default to enable threads? ? You can't ever turn it off?
