[llvm-dev] [yaml2obj] GSoC-20: Add DWARF support to yaml2obj

[Robinson, Paul via llvm-dev]

> -----Original Message-----
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Pavel Labath
> via llvm-dev
> Sent: Monday, April 27, 2020 9:16 AM
> To: jh7370.2008 at my.bristol.ac.uk; Greg Clayton <clayborg at gmail.com>
> Cc: Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org>; Xing GUO
> <higuoxing at gmail.com>
> Subject: Re: [llvm-dev] [yaml2obj] GSoC-20: Add DWARF support to yaml2obj
> 
> On 27/04/2020 10:10, James Henderson wrote:
> > I believe the compiler will generate a .debug_ranges section if you use
> > -ffunction-sections, since the addresses of sections will be
> > non-contiguous. From there, you should be able to edit the .debug_ranges
> > assembly as needed (replace references to symbols with 0s in the
> > .debug_ranges content) to get the exact behaviour you want (I'm assuming
> > you don't want to have to hand-edit a .debug_abbrev/.debug_info data
> > structure to manually create a .debug_ranges).
> 
> Yeah, that's what I usually do -- get the compiler to emit something
> close to what I need, and then edit the assembly to produce the exact
> needed input, or to remove things which are completely irrelevant.
> 
> pl

that said, any non-trivial example involving .debug_info quickly becomes
difficult for humans to read because of the multiple sections involved--
.debug_info points to .debug_abbrev, possibly .debug_ranges/rnglists or
.debug_loc/loclists, maybe .debug_addr, certainly .debug_str, ....

A "DWARF compiler" or at least a "DWARF assembler" that took care of all
the picky details would be a nice tool to have, IMO.
--paulr