Re: MORE OFFTOPIC Re: I've just released Vasaro
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. :-)
Re: MORE OFFTOPIC Re: I've just released Vasaro
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
Re: MORE OFFTOPIC Re: I've just released Vasaro
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
Re: MORE OFFTOPIC Re: I've just released Vasaro
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
Re: MORE OFFTOPIC Re: I've just released Vasaro
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.
Re: MORE OFFTOPIC Re: I've just released Vasaro
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
MORE OFFTOPIC Re: I've just released Vasaro
On Monday, 10 December 2018 at 10:47:42 UTC, Jacob Carlborg wrote:
On 2018-12-08 18:01, Adam D. Ruppe wrote:
The one I have is a macbook air with a broken, but usable
screen (I got it for free yay). I don't know how old it is, I
*think* it is a 2013 model.
If you click on the Apple menu in the top left corner and
choose "About This Mac", it will say which model and which year
in the window that appears. It will also specify which version
of the OS it's running.
I know it won't take the new OS update from Apple, but it was
able to run dmd on it last time I tried (which was like 9
months ago lol).
DMD will run on Mavericks (10.9) or later.
I have a 10.6 that I will be re-adding port of druntime/phobos to
(2.076 and later), and I think gcc also has a 10.4 in their
server farm.
Anything that I find is missing that belongs in common parts I'll
raise a pull to re-add, as it costs us nothing to support it.
Is there any consideration apart from section/tls support? 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. As
for tls, well there is still no native support in gcc if I
understand correctly.
