[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