[llvm-dev] workaround to force LLD to make dwarf info sections mappable/loadable?

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Mon Dec 3 14:29:45 PST 2018


On Mon, Dec 3, 2018 at 2:24 PM Andrew Kelley <andrew at ziglang.org> wrote:

> On 12/3/18 5:10 PM, Rui Ueyama wrote:
> > I think Eli made a good point.
>
> Eli's point seems to be "your use case is not valid", which I will
> consider, but it doesn't really work towards solving the problem as stated.
>
> > In addition to that, if you are writing a
> > OS kernel, I guess you are also writing a loader, so you can map
> > anything as you want, no?
>
> Well, I don't have a loader written yet, and I want to use this stack
> trace feature while working on it. But even if I did, the addresses in
> the ELF file produced by LLD are incoherent, and so it would not be
> possible to map them.
>
> Another alternative would be to ship debug symbol files separately on a
> file system. I also don't have a file system written yet.
>
> The bottom line is that, there's no fundamental reason this cannot work;
> it is a quirk of conventions that is unnecessarily preventing the debug
> info from being mapped into memory.
>

Yes, there's no fundamental reason this cannot work. Rather, it should
work. It does not immediately mean that lld needs to work for such linker
script, since we intentionally try to not work too hard to support 100%
linker script compatibility with GNU ld, as it's not strictly doable due to
the lack of a formal specification, and as it is sometimes extremely
tricky. That said, it is probably worth taking a look at why this doesn't
work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181203/4d72dd44/attachment.html>


More information about the llvm-dev mailing list