Andrew Kelley via llvm-dev
2018-Dec-03 20:34 UTC
[llvm-dev] 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>
Friedman, Eli via llvm-dev
2018-Dec-03 22:05 UTC
[llvm-dev] workaround to force LLD to make dwarf info sections mappable/loadable?
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
Rui Ueyama via llvm-dev
2018-Dec-03 22:10 UTC
[llvm-dev] 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>