This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug other/39888] TLS emutls not linked to automatically on Darwin



------- Comment #7 from developer at sandoe-acoustics dot co dot uk  2009-09-22 19:20 -------
(In reply to comment #6)
> I wonder if we could just trim out the symbols from libgcc that are in
> libSystem, and arrange for gcc's installed libgcc to be found first. 

OK. If I understand this from the symbol PoV 
- that's the same machinery as builds the _ext 
(i.e. there are the same symbols left at each revision as would be in the _ext
)...
in a change-control sense, at least.

> Advantage, simplicity, less target specific work, easy to understand.
Simplicity & less work sound good... I'm working on the understanding bit ;)

> Downside, OS upgrades require recompiling the world, to the extent there are
> new symbols in libgcc that are then added to libSystem in later OS releases. 

meaning that a binary from on OSX release would not work on a later one or vice
versa.  
I guess there's an amount of this anyway .. 

> ld has magic in it that can appear and disappear symbols from a dylib depending
> upon which OS is targeted.  Target old OSes, all the usual symbols are there,
> target newer OSes, large swaths disappear (but are found anyway in libSystem).
>
> Also, all this fun stuff it relevant to darwin10 and later only (not darwin9). 

why not relevant to D9 and D8?
(D8 is still the end of the road for a whole bunch of perfectly good PPC
hardware)

if we override the /usr/lib/libgcc_s we mess up the unwinding 
(the whole reason I made the _ext in the first place was that we can't 'lose' 
that version because it's linked with system frameworks.)

To add symbols to D9/D8 we still have to link two libgcc variants (whether one
is named _ext or not is not important) ..

> I'm not a fan of yet more compile flags in general.  I'd rather have a nice
> design that covers the bases, that doesn't really need yet more flags.
> 
> The hiding trick goes something like:
> 
>     #define NOT_HERE_BEFORE_10_6(sym) \
>         extern const char sym##_tmp3 __asm("$ld$hide$os10.3$_" #sym ); \
>             __attribute__((visibility("default"))) const char sym##_tmp3 = 0; \

where do we have to apply this macro ? 
to every function in libgcc? (with appropriate 'NOT_HERE_BEFOREs' )
or is it something that could be scripted?


-- 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]