[PATCH] Emit DWARF info for all code section in an assembly file

Eric Christopher echristo at gmail.com
Mon Feb 10 15:36:58 PST 2014


On Wed, Feb 5, 2014 at 1:58 AM, Keith Walker <kwalker at arm.com> wrote:
>
>
>> -----Original Message-----
>> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
>>
>> On Tue, Feb 4, 2014 at 10:26 AM, Adrian Prantl <aprantl at apple.com>
>> wrote:
>> > Hi Oliver,
>> >
>> > generally, Doxygen comments for the new functions never hurt.
>> >
>> > One question:
>> > It looks like we're hardcoding a version here:
>> >
>> > -  // The 2 byte DWARF version, which is 2.
>> > -  MCOS->EmitIntValue(2, 2);
>> > +  // The 2 byte DWARF version, which is 3.
>> > +  MCOS->EmitIntValue(3, 2);
>> >
>> > Shouldn't this be somehow derived from the version attribute in the
>> module?
>> > E.g., clang -gdwarf-2 will result in a Module attribute like
>> >
>> >   !0 = metadata !{i32 2, metadata !"Dwarf Version", i32 2},
>> >
>> > and then for example, we should never emit anything that needs Dwarf3
>> features.
>>
>> No metadata in an assembly file :)
>>
>> That said it should be controlled by command line option if you don't
>> mind Oliver. -gdwarf-N.
>
> This change uses the .debug_ranges section, which was introduced in DWARF-3,

Wait, is this using aranges or ranges? (Honestly it should, sadly, be
doing both).

> in order to describe the situation when code for a compilation unit
> (assembler file) is split into non-contiguous address ranges (sections
> containing instructions).
>

Right.

> Therefore this approach does not work for DWARF-2 which doesn't support
> .debug_ranges.
>

But does support debug_aranges.

> I see 3 possible options:
>
> 1.   Produce an warning or error if using -gdwarf-2 and there are
> non-contiguous address ranges being produced.

Reasonable, but a bit of work I imagine.

> 2.   Rather than using .debug_ranges, produce multiple compilation unit
> entries each one describing the code for a separate section.

Eew.

> 3.   Just don't support -gdwarf-2 at all ... does anyone know if there are
> any toolchains which require DWARF-2 that need to be supported?
>

I think darwin might for now.

-eric



More information about the llvm-commits mailing list