On 2018-12-10 12:26, Iain Buclaw wrote:

> Is there any consideration apart from section/tls support? 

There's the backtrace implementation for exceptions as well, "rt.backtrace". I had to slight modify the DMD backend to get that to work the same as it does on Linux and FreeBSD. I've documented how it's implemented in the commit message [1].

> I'm just going to fork the current rt.sections stuff (I.e: gcc.sections.{elf,macho,pef,x off}) as apart from linux/elf, the rest is not of any use or is specific to dmd object format. 

You should be able to reuse most parts of rt.sections_osx_x86. I don't think there's anything in that file that won't work on x86-64. But you would need to adjust it for the TLS implementation you're using.

> As for tls, well  there is still no native support in gcc if I understand correctly.

It was pretty straight forward (once I figured it out :) ) to implement in DMD and it's pretty well documented you want to implement it in GCC.

[1] https://github.com/dlang/dmd/commit/2bf7d0db29416eacbb01a91e6502140e354ee0ef

-- 
/Jacob Carlborg

On Tuesday, 11 December 2018 at 10:30:54 UTC, Jacob Carlborg wrote:
> On 2018-12-10 12:26, Iain Buclaw wrote:
>
>> Is there any consideration apart from section/tls support?
>
> There's the backtrace implementation for exceptions as well, "rt.backtrace". I had to slight modify the DMD backend to get that to work the same as it does on Linux and FreeBSD. I've documented how it's implemented in the commit message [1].
>

We're covered by libbacktrace, rather than tthe druntime implementation.

https://github.com/gcc-mirror/gcc/blob/master/libbacktrace/README

>> I'm just going to fork the current rt.sections stuff (I.e: gcc.sections.{elf,macho,pef,x off}) as apart from linux/elf, the rest is not of any use or is specific to dmd object format.
>
> You should be able to reuse most parts of rt.sections_osx_x86. I don't think there's anything in that file that won't work on x86-64. But you would need to adjust it for the TLS implementation you're using.
>

Unlike dmd, we don't really have full control over how things end up in the object.  There are a couple coaxing methods used which allowed us to use elf_shared without modification.  Other object formats I don't think we'll be so lucky over.

I'll try really hard though to keep the same implementation used for elf in others however - just different section names depending on what is accepted by the assembler.

>> As for tls, well  there is still no native support in gcc if I understand correctly.
>
> It was pretty straight forward (once I figured it out :) ) to implement in DMD and it's pretty well documented you want to implement it in GCC.
>

I'll leave that to the binutils people.  Supporting emutls also means we'll work on mingw too, which has a similar say story regarding state of native tls.

Besides, it will only work for newer OSX releases, not ~10.5 which is roughly the base version aimed to support.

On 2018-12-11 12:13, Iain Buclaw wrote:

> We're covered by libbacktrace, rather than tthe druntime implementation.
> 
> https://github.com/gcc-mirror/gcc/blob/master/libbacktrace/README

Looks like Mach-O is not supported. It looks like it uses DWARF, but I don't know how you plan to have that working when the executable doesn't contain any DWARF data ;).

> Besides, it will only work for newer OSX releases, not ~10.5 which is roughly the base version aimed to support.

I still don't see any point in supporting these old version that Apple has dropped support for since many years ago.

-- 
/Jacob Carlborg

On Tuesday, 11 December 2018 at 11:24:37 UTC, Jacob Carlborg wrote:
> On 2018-12-11 12:13, Iain Buclaw wrote:
>
>> We're covered by libbacktrace, rather than tthe druntime implementation.
>> 
>> https://github.com/gcc-mirror/gcc/blob/master/libbacktrace/README
>
> Looks like Mach-O is not supported. It looks like it uses DWARF, but I don't know how you plan to have that working when the executable doesn't contain any DWARF data ;).
>
>> Besides, it will only work for newer OSX releases, not ~10.5 which is roughly the base version aimed to support.
>
> I still don't see any point in supporting these old version that Apple has dropped support for since many years ago.

Dwarf data is emitted on OSX. The section where to find all debug symbols is prefixed by "__DWARF".  Even DMD does this on OSX. ;-)

https://github.com/dlang/dmd/blob/dff0138467ec451ac64e1dac392a1a9648ee2523/src/dmd/backend/dwarfdbginf.d#L150-L151

On 2018-12-11 13:23, Iain Buclaw wrote:

> Dwarf data is emitted on OSX. The section where to find all debug
> symbols is prefixed by "__DWARF".  Even DMD does this on OSX. ;-)

Yes, but the linker strips any sections with the "S_ATTR_DEBUG" flag, which includes the everything in the "__DWARF" segment. Here's my commit message for convenience:

The linker on macOS will remove any debug info, i.e. every section
with the `S_ATTR_DEBUG` flag, this includes everything in the
`__DWARF` section. By using the `S_REGULAR` flag the linker will not
remove this section. This allows to get the filenames and line numbers
for backtraces from the executable.

Normally the linker removes all the debug info but adds a reference to
the object files. The debugger can then read the object files to get
filename and line number information. It's also possible to use an
additional tool that generates a separate `.dSYM` file. This file can
then later be deployed with the application if debug info is needed
when the application is deployed.

-- 
/Jacob Carlborg

On Tuesday, 11 December 2018 at 16:32:31 UTC, Jacob Carlborg wrote:
> On 2018-12-11 13:23, Iain Buclaw wrote:
>
>> Dwarf data is emitted on OSX. The section where to find all debug
>> symbols is prefixed by "__DWARF".  Even DMD does this on OSX. ;-)
>
> Yes, but the linker strips any sections with the "S_ATTR_DEBUG" flag, which includes the everything in the "__DWARF" segment. Here's my commit message for convenience:
>
> The linker on macOS will remove any debug info, i.e. every section
> with the `S_ATTR_DEBUG` flag, this includes everything in the
> `__DWARF` section. By using the `S_REGULAR` flag the linker will not
> remove this section. This allows to get the filenames and line numbers
> for backtraces from the executable.
>
> Normally the linker removes all the debug info but adds a reference to
> the object files. The debugger can then read the object files to get
> filename and line number information. It's also possible to use an
> additional tool that generates a separate `.dSYM` file. This file can
> then later be deployed with the application if debug info is needed
> when the application is deployed.

Well, as a front-end language dev, how gcc emits things is not my bailiwick, just so long as I can guarantee language semantics. :-)

On Tuesday, 11 December 2018 at 10:19:38 UTC, Jacob Carlborg wrote:
> Which year is the machine from? It should say that after the model.

Oh, I had to click "more info".

MacBook Air
11-inch, Mid 2011

So I guess it is quite old. I have tried to do the OS update several times before and it consistently just freezes (usually the progress bar stops, the system keeps working, but one time it did outright restart itself), this probably explains why.

> I would recommend waiting until more of the Objective-C support is implemented. Creating a subclass is a pain in the ass currently.

Yeah, I know. I have made some mixins to help smooth it over a little though. That is one of the reasons why I am waiting a bit, but I feel if I wait on dmd I'll be waiting forever. I'd like at least the basics to work.

On Tuesday, 11 December 2018 at 10:19:38 UTC, Jacob Carlborg wrote:
> I would recommend waiting until more of the Objective-C support is implemented. Creating a subclass is a pain in the ass currently.

So I got out my code that (with your help about a year ago) was doing a hello world window and menu, but now it doesn't compile, complaining about a hidden Class clashing with my Class.

What is the current state and roadmap for this support? The stuff described here seems wrong: https://dlang.org/spec/objc_interface.html and this apparently hasn't been edited for years: https://wiki.dlang.org/DIP43 but SEEMS to be what closest matches up.

On 2018-12-12 15:52, Adam D. Ruppe wrote:
> On Tuesday, 11 December 2018 at 10:19:38 UTC, Jacob Carlborg wrote:
>> Which year is the machine from? It should say that after the model.
>
> Oh, I had to click "more info".
>
> MacBook Air
> 11-inch, Mid 2011
>
> So I guess it is quite old. I have tried to do the OS update several
> times before and it consistently just freezes (usually the progress bar
> stops, the system keeps working, but one time it did outright restart
> itself), this probably explains why.


Yes, it's too old for Mojave. But it looks like you can run High Sierra [1]. It's just one version old.

[1] https://support.apple.com/kb/SP765?locale=en_US

-- 
/Jacob Carlborg

On 2018-12-13 00:36, Adam D. Ruppe wrote:

> So I got out my code that (with your help about a year ago) was doing a
> hello world window and menu, but now it doesn't compile, complaining
> about a hidden Class clashing with my Class.

Hmm, it was not my intention for that to be exposed yet.

You don't need that hack with an extra interface called "Class" anymore. It's now possible to declare static/class methods directly, which wasn't possible before.

Technically in Objective-C static methods are instance methods on the metaclass. All classes in Objective-C are objects, they're instance of the metaclass. Each class has a corresponding metaclass. The class/interface you have implemented called "Class" was the metaclass, manually declared. This metaclass is normally not visible in the source code in Objective-C. What we did was we declared instance methods on the metaclass, this is now handled behind the scenes when you're declaring a method with "static" in the normal class/interface.

If you're code is looking like this:

extern (Objective-C) interface Foo
{
    extern (Objective-C) interface Class
    {
        Foo alloc() @selector("alloc");
    }
}

You can now replace it with this code:

extern (Objective-C) interface Foo
{
    static Foo alloc() @selector("alloc");
}

And you can directly call "Foo.alloc()".

It was not my intention to break existing code. I think if you rename your "Class" to something else it will continue to work.

> What is the current state and roadmap for this support?

There's no roadmap. It's whenever I got time to work on the Objective-C integration. Lately I've been prioritizing other work. But it would be the next thing on the list of Objective-C features to implement.

> The stuff described here seems wrong: https://dlang.org/spec/objc_interface.html

No, that's correct. The example at the bottom compiles and runs correctly using DMD 2.083.0.

> and this apparently hasn't been edited for years:
> https://wiki.dlang.org/DIP43 but SEEMS to be what closest matches up.

I'm not sure if DIP43 needs to be changed. It's what I'm following when implementing, more or less. It's just that not everything in DIP43 has been implemented yet.

-- 
/Jacob Carlborg