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

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. I have this in my linker script:

    .debug_info : {
        __debug_info_start = .;
        KEEP(*(.debug_info))
        __debug_info_end = .;
    }
    .debug_abbrev : {
        __debug_abbrev_start = .;
        KEEP(*(.debug_abbrev))
        __debug_abbrev_end = .;
    }
    .debug_str : {
        __debug_str_start = .;
        KEEP(*(.debug_str))
        __debug_str_end = .;
    }
    .debug_line : {
        __debug_line_start = .;
        KEEP(*(.debug_line))
        __debug_line_end = .;
    }
    .debug_ranges : {
        __debug_ranges_start = .;
        KEEP(*(.debug_ranges))
        __debug_ranges_end = .;
    }

But LLD maps these sections to address 0:

00000000000003ac g       .debug_abbrev  0000000000000000 __debug_abbrev_end
0000000000000000 g       .debug_abbrev  0000000000000000
__debug_abbrev_start
0000000000009da5 g       .debug_info  0000000000000000 __debug_info_end
0000000000000000 g       .debug_info  0000000000000000 __debug_info_start
0000000000006aba g       .debug_line  0000000000000000 __debug_line_end
0000000000000000 g       .debug_line  0000000000000000 __debug_line_start
0000000000001bf0 g       .debug_ranges  0000000000000000 __debug_ranges_end
0000000000000000 g       .debug_ranges  0000000000000000
__debug_ranges_start
000000000000399f g       .debug_str 0000000000000000 __debug_str_end
0000000000000000 g       .debug_str 0000000000000000 __debug_str_start


is there a workaround to force LLD to make these sections
mappable/loadable so that the executable can access them?

Regards,
Andrew

-------------- 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/511a078e/attachment.sig>

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

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>