Fix Issue 18068 - No file names and line numbers in stack trace

[JinShil]

This is an attempt at adopting #2172

[dlang-bot]

Thanks for your pull request, @JinShil!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	18068	regression	No file names and line numbers in stack trace

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "stable + druntime#2230"

[wilzbach]

You probably want to target stable?

[JinShil]

I've targeted stable and completely removed the shared library tests. To compensate, I've submitted https://issues.dlang.org/show_bug.cgi?id=19016 and I think we should leave #2172 open so we can revisit the shared library case there.

[jacob-carlborg]

To compensate, I've submitted https://issues.dlang.org/show_bug.cgi?id=19016 and I think we should leave #2172 open so we can revisit the shared library case there.

As far as I can see support for shared libraries are not supported at all. The existing code only opens and reads the current executable, not any shared libraries.

By using this approach (reading the executable from disk) there's another edge case that I think will fail. If the application is started and then the executable is removed this will not work. It should work on macOS because there it's possible to get a handle to the executable from memory without reading from disk.

[JinShil]

@jacob-carlborg You are correct, but the bug is a regression, and this PR restores functionality, and will be quite a relief for many users in most use cases. I've already submitted the issue about shared libraries, so can we submit an issue about the fact that this implementation is reading from a disk instead of memory, and then merge this?

[jacob-carlborg]

For me this is ready to be merged, I already approved it. Perhaps squash the commits. I would like someone else to give their approval as well before merging.

I don't see much difference compared to #2172. As far as I can see, the code in #2172 will not make this work with shared libraries. Is there a reason to keep #2172 open?

[JinShil]

Is there a reason to keep #2172 open?

The only reason I see to keep #2172 open is because it contains work that can be used to eventually test support for shared libraries, and has some good information for anyone further pursuing this development. Though, I admit it doesn't have to remain open for that; I already added a link to it in the shared library bugzilla issue, and that information will still be accessible even if it were closed.

[wilzbach]

@JinShil thanks a lot for pushing this. It got somehow lost in my TODO list. Sorry!
It looks like you forgot to target stable. I did so for you, squashed everything and modified the "fallback" comment.
Let's get this finally in, s.t. it can be part of the upcoming 2.081!

[Boris-Barboris]

Reappeared on Arch about two weeks ago when glibc was updated (to 2.28). I have tried ubuntu with old glibc and file names and line numbers are all in place.
Glibc was not the only thing that updated however.
glibc 2.28-1
binutils 2.31.1-1
4.17.12-arch1-1-ARCH
dmd-2.081.1