When manually linking with lld, stack traces loses source locations and function names, even though the same archive linked with Apple ld works.
I am aware that lld is not supported for Apple targets. However, our project uses build-lib / build-obj and defers final linking to lld, because we build many different libraries from various languages and want a uniform final link step.
Digging a bit, I see that MachOFile.load state machine currently expects the Apple ld layout with N_BNSYM / N_ENSYM markers, while ld64.lld emits N_FUN entries without those.
From a bit of research, I found https://reviews.llvm.org/D89257 which states:
...
we do not emit N_BNSYM and N_ENSYM STABS to mark the start and end of functions,
because the N_FUN STABS already serve that purpose.
...
I have a very small patch ready to be submitted in case you deemed acceptable to support this use-case.
When manually linking with `lld`, stack traces loses source locations and function names, even though the same archive linked with Apple `ld` works.
I am aware that `lld` is not supported for Apple targets. However, our project uses `build-lib` / `build-obj` and defers final linking to `lld`, because we build many different libraries from various languages and want a uniform final link step.
Digging a bit, I see that `MachOFile.load` state machine currently expects the Apple `ld` layout with `N_BNSYM` / `N_ENSYM` markers, while `ld64.lld` emits `N_FUN` entries without those.
From a bit of research, I found https://reviews.llvm.org/D89257 which states:
```
...
we do not emit N_BNSYM and N_ENSYM STABS to mark the start and end of functions,
because the N_FUN STABS already serve that purpose.
...
```
I have a very small patch ready to be submitted in case you deemed acceptable to support this use-case.