Sorry for a long chain on OSX.  But one last unresolved symbol from make check-d: "_d_osx_image_init".  Is it just a placeholder or is it hidden somewhere.  Does gdc still need the code to set setup gc scanning?  How is TLS on OSX? - if not ready, would emutls work?
-- 
Dan

On 5 June 2015 at 08:40, Dan Olson via D.gnu <d.gnu@puremagic.com> wrote:
>
> Sorry for a long chain on OSX.  But one last unresolved symbol from make check-d: "_d_osx_image_init".  Is it just a placeholder or is it hidden somewhere.  Does gdc still need the code to set setup gc scanning?  How is TLS on OSX? - if not ready, would emutls work?
> --
> Dan

I hope I'm not shying you away by saying, this is what someone needs to find out.

I'd first suggest to build gcc only and test what is outputted.  Use a test program such as __thread int tls;  and a main program that sets it's value to 0xdeadbeef then build with -S and check if the output shows calls to emutls like functions.

GDC already has GC support for emutls, so the interesting part is if GCC does native tls on osx.

On 5 Jun 2015 08:05, "Dan Olson via D.gnu" <d.gnu@puremagic.com> wrote:
>
> Dan Olson <gorox@comcast.net> writes:
>
> > Looks like I need to track down missing symbols from rt.tlsgc now. I think it is becoming a fun puzzle :-) The arm stuff can wait.
>
> How do I tell gdc that OS X needs target specific underscore "_" prefix added to pragma(mangle, name)?  thread.d uses core.internal.traits.externDFunc.  That is cause.  For now I worked around with:
>
> pragma(mangle, "_"~mangleFunc!T(fqn)) mixin(decl);

That's interesting, it should do that for you automatically, there should be only one reason why that doesn't happen, and I don't use it for pragma mangle.

"Iain Buclaw via D.gnu" <d.gnu@puremagic.com> writes:

> I hope I'm not shying you away by saying, this is what someone needs to find out.

No, not at all. I've gotten pretty used to puzzling through TLS implementations for LDC porting.

> I'd first suggest to build gcc only and test what is outputted. Use a test program such as __thread int tls; and a main program that sets it's value to 0xdeadbeef then build with -S and check if the output shows calls to emutls like functions.
>
> GDC already has GC support for emutls, so the interesting part is if GCC does native tls on osx.

Yep, I'll try it.

"Iain Buclaw via D.gnu" <d.gnu@puremagic.com> writes:

> On 5 Jun 2015 08:05, "Dan Olson via D.gnu" <d.gnu@puremagic.com> wrote:
>
> That's interesting, it should do that for you automatically, there should be only one reason why that doesn't happen, and I don't use it for pragma mangle.

That is what I expected too based on previous digitalmars.D thread when you described gdc mangle and mangleof.

On 6 June 2015 at 16:53, Dan Olson via D.gnu <d.gnu@puremagic.com> wrote:

> "Iain Buclaw via D.gnu" <d.gnu@puremagic.com> writes:
>
> > On 5 Jun 2015 08:05, "Dan Olson via D.gnu" <d.gnu@puremagic.com> wrote:
> >
> > That's interesting, it should do that for you automatically, there should be only one reason why that doesn't happen, and I don't use it for pragma mangle.
>
> That is what I expected too based on previous digitalmars.D thread when you described gdc mangle and mangleof.
>

Alas, after looking at backend, it turns out that the answer is no.

In the glue sources (d-decls.cc), replace 'set_user_assembler_name' with 'SET_DECL_ASSEMBLER_NAME' and rebuild the module without your workaround.

Regards
Iain.

"Iain Buclaw via D.gnu" <d.gnu@puremagic.com> writes:

> On 5 June 2015 at 08:40, Dan Olson via D.gnu <d.gnu@puremagic.com> wrote:
>>
>> Sorry for a long chain on OSX. But one last unresolved symbol from
> make
>> check-d: "_d_osx_image_init". Is it just a placeholder or is it
> hidden
>> somewhere. Does gdc still need the code to set setup gc scanning?
> How
>> is TLS on OSX? - if not ready, would emutls work?
>> --
>> Dan
>
> I hope I'm not shying you away by saying, this is what someone needs to find out.
>
> I'd first suggest to build gcc only and test what is outputted. Use a test program such as __thread int tls; and a main program that sets it's value to 0xdeadbeef then build with -S and check if the output shows calls to emutls like functions.
>
> GDC already has GC support for emutls, so the interesting part is if GCC does native tls on osx.

GCC with vanilla configure is generating emutls calls for OSX.

On 6 June 2015 at 18:18, Dan Olson via D.gnu <d.gnu@puremagic.com> wrote:

> "Iain Buclaw via D.gnu" <d.gnu@puremagic.com> writes:
>
> > On 5 June 2015 at 08:40, Dan Olson via D.gnu <d.gnu@puremagic.com> wrote:
> >>
> >> Sorry for a long chain on OSX. But one last unresolved symbol from
> > make
> >> check-d: "_d_osx_image_init". Is it just a placeholder or is it
> > hidden
> >> somewhere. Does gdc still need the code to set setup gc scanning?
> > How
> >> is TLS on OSX? - if not ready, would emutls work?
> >> --
> >> Dan
> >
> > I hope I'm not shying you away by saying, this is what someone needs to find out.
> >
> > I'd first suggest to build gcc only and test what is outputted. Use a test program such as __thread int tls; and a main program that sets it's value to 0xdeadbeef then build with -S and check if the output shows calls to emutls like functions.
> >
> > GDC already has GC support for emutls, so the interesting part is if GCC does native tls on osx.
>
> GCC with vanilla configure is generating emutls calls for OSX.
>

So, we can safely remove all references to _d_osx_image_init from
rt.memory, but keep the second version(OSX) as you don't want a static
assert. ;-)

"Iain Buclaw via D.gnu" <d.gnu@puremagic.com> writes:

> Alas, after looking at backend, it turns out that the answer is no.
>
> In the glue sources (d-decls.cc), replace 'set_user_assembler_name' with 'SET_DECL_ASSEMBLER_NAME' and rebuild the module without your workaround.

Ok, that works for data.  Functions (stuff in text section) still
missing _.  Is that handled by same function? (VarDeclaration::toSymbol)

On 6 June 2015 at 18:33, Iain Buclaw <ibuclaw@gdcproject.org> wrote:

> On 6 June 2015 at 18:18, Dan Olson via D.gnu <d.gnu@puremagic.com> wrote:
>
>> "Iain Buclaw via D.gnu" <d.gnu@puremagic.com> writes:
>>
>> > On 5 June 2015 at 08:40, Dan Olson via D.gnu <d.gnu@puremagic.com> wrote:
>> >>
>> >> Sorry for a long chain on OSX. But one last unresolved symbol from
>> > make
>> >> check-d: "_d_osx_image_init". Is it just a placeholder or is it
>> > hidden
>> >> somewhere. Does gdc still need the code to set setup gc scanning?
>> > How
>> >> is TLS on OSX? - if not ready, would emutls work?
>> >> --
>> >> Dan
>> >
>> > I hope I'm not shying you away by saying, this is what someone needs to find out.
>> >
>> > I'd first suggest to build gcc only and test what is outputted. Use a test program such as __thread int tls; and a main program that sets it's value to 0xdeadbeef then build with -S and check if the output shows calls to emutls like functions.
>> >
>> > GDC already has GC support for emutls, so the interesting part is if GCC does native tls on osx.
>>
>> GCC with vanilla configure is generating emutls calls for OSX.
>>
>
> So, we can safely remove all references to _d_osx_image_init from
> rt.memory, but keep the second version(OSX) as you don't want a static
> assert. ;-)
>

But just to self reflect on that, maybe in it's place inline the old
memory_osx but with TLS sections/handling removed:
https://github.com/D-Programming-GDC/GDC/blob/0907d30b8a45036a7497d284d3210b899122cce6/libphobos/libdruntime/rt/memory_osx.d

Is probably something like this:  http://dpaste.dzfl.pl/e55824cab9c3