llvm dev - Dec 2018 - workaround to force LLD to make dwarf info sections mappable/loadable?

I think Eli made a good point. 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?

On Mon, Dec 3, 2018 at 2:06 PM Friedman, Eli via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 12/3/2018 12:34 PM, Andrew Kelley via llvm-dev wrote:
> > Context: https://bugs.llvm.org/show_bug.cgi?id=39862
> >
> > I'm trying to enable stack traces in an OS kernel. To do that the
kernel
> > needs access to its own debug info.
>
> Unwind info is usually emitted into an allocatable section, so you can
> compute a stack trace without looking at debug info. Of course, that
> doesn't include any symbol information, but you can compute the
> corresponding symbols offline.
>
> IIRC the Linux kernel uses a custom format for symbol information; the
> build system post-processes the object files to compute the relevant
> information, and uses objcopy to insert the information into an
> allocatable section.
>
> -Eli
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181203/ab0cc1fe/attachment.html>

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181203/f92900ad/attachment.sig>

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>

On 12/3/18 5:24 PM, Andrew Kelley via llvm-dev wrote:
> 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.
One more thing - this project as it currently exists is a proof of
concept of how a bare bones embedded system executable running on bare
metal can still have the same advanced debugging capabilities as when
using, e.g. Linux. If the debug info can be directly mapped, and thus
eliminate a dependency on a file system or on a special bootloader, it's
a great demo.

I think this use case is valid.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181203/1783c58b/attachment.sig>