https://issues.dlang.org/show_bug.cgi?id=20510

--- Comment #1 from Mathias LANG <pro.mathias.lang@gmail.com> ---
For reference, more informations about the scheme can be found here: http://wiki.dwarfstd.org/index.php?title=Apple%27s_%22Lazy%22_DWARF_Scheme

The same person has written a SO answer here: https://stackoverflow.com/a/12827463

--

https://issues.dlang.org/show_bug.cgi?id=20510

Mathias LANG <pro.mathias.lang@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |20460


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=20460
[Issue 20460] [OSX] DMD writes the same address everywhere in DWARF debug infos
--

https://issues.dlang.org/show_bug.cgi?id=20510

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |symdeb
                 CC|                            |bugzilla@digitalmars.com

--

https://issues.dlang.org/show_bug.cgi?id=20510
Issue 20510 depends on issue 20460, which changed state.

Issue 20460 Summary: [OSX] DMD writes the same address everywhere in DWARF debug infos https://issues.dlang.org/show_bug.cgi?id=20460

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--

https://issues.dlang.org/show_bug.cgi?id=20510

--- Comment #2 from Mathias LANG <pro.mathias.lang@gmail.com> ---
I have a WIP locally so anyone interested, feel free to contact me. As a reference, this is how LLVM looks up UUID: https://lldb.llvm.org/use/symbols.html

--

https://issues.dlang.org/show_bug.cgi?id=20510

Johan Engelen <jbc.engelen@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jbc.engelen@gmail.com

--- Comment #3 from Johan Engelen <jbc.engelen@gmail.com> ---
Hi Matthias,
  Have you considered letting druntime call an external symbolizer like
llvm-symbolizer?
https://llvm.org/docs/CommandGuide/llvm-symbolizer.html
llvm-symbolizer will do all the heavy lifting of interpreting dSYM.
llvm-symbolizer does not even require the generation of dSYM folder by
dsymutil; it's what Address Sanitizer uses, and it works fine for me on macOS.

-Johan

--

https://issues.dlang.org/show_bug.cgi?id=20510

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

https://issues.dlang.org/show_bug.cgi?id=20510

johanengelen@weka.io changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johanengelen@weka.io

--- Comment #4 from johanengelen@weka.io ---
LDC druntime implementation using `atos`: https://github.com/ldc-developers/ldc/pull/4291

--

https://issues.dlang.org/show_bug.cgi?id=20510

Sönke Ludwig <sludwig@outerproduct.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sludwig@outerproduct.org

--- Comment #5 from Sönke Ludwig <sludwig@outerproduct.org> ---
Just a comment regarding the practicality of the atos approach, which is now also being adopted by DMD - we've had quite bad experiences with this in most situations:

- On some development machines, the call stack terminates after two frames, without any useful information

- In production, it is not possible at all to get useful stack traces from user installations

- Utmost care must be taken to not throw exceptions frequently, because an atos run can easily block the thread for 100ms (or rather not to log the associated stack traces frequently)

All in all, while the earlier situation without line numbers was pretty bad, it has become almost as bad as it can get in our case.

--