[llvm-commits] [llvm] r169218 - in /llvm/trunk: include/llvm/ lib/CodeGen/AsmPrinter/ lib/VMCore/ test/CodeGen/ARM/ test/CodeGen/Thumb/ test/CodeGen/X86/ test/DebugInfo/ test/DebugInfo/X86/ test/JitListener/

David Blaikie dblaikie at gmail.com
Wed Dec 5 13:51:24 PST 2012


On Wed, Dec 5, 2012 at 1:29 PM, Robinson, Paul
<Paul.Robinson at am.sony.com> wrote:
> David Blaikie wrote:
>>On Wed, Dec 5, 2012 at 11:29 AM, Eric Christopher <echristo at gmail.com> wrote:
>>> On Wed, Dec 5, 2012 at 11:25 AM, Bill Wendling <isanbard at gmail.com> wrote:
>>>> Okay. The fix is to emit the lower bound in all cases. I don't think this
>>>> will be a problem for the debugger. It just adds extra information that
>>>> it'll probably ignore in C/C++. :)
>>>
>>>
>>> No, it's not. The correct is to omit it when the lower bound is the same as
>>> the default lower bound which I just gave in this thread :)
>>
>> (I'm not sure I'm helping here, but I'm confused as to the degree of
>> talking-past that's gone on with this issue... hopefully I'm doing
>> more good than harm)
>
> Even if the only good is to improve your understanding, that's more
> good than harm and a worthwhile thing.
>
>> Frontends (Clang, DragonEgg, etc) know which language they're emitting
>> debug info for & what the default is. They emit lower bounds whenever
>> the bound is not the language-specific default.
>> Backend (LLVM) unconditionally emits whatever the frontend gave it.
>>
>> & thus we get the minimum required debug info: values when they're not
>> the default, relying on the default when it matches.
>>
>> Unless I'm misunderstanding something,
>> - David
>
> Frontends clearly know the default for their own language.  However,
> the debug-info metadata passed to the backend doesn't allow the frontend
> to omit the lower bound; after Bill's recent hacking, a subrange's bounds
> are passed as a (lowerbound, count) duple.
>
> The backend then wants to emit DWARF as compactly as it reasonably can,
> which in this case means omitting the explicit lower bound if that bound
> matches the language-specific default specified by the DWARF standard.
>
> The bug I pointed out is that LLVM was omitting the lower bound if that
> bound was zero, which matches the language-specific default for some
> languages (e.g. C/C++) but not others (e.g. FORTRAN, Ada).  Bill
> has now been assigned to fix that (yay!).

Right - I got that, I think. Eric explained some more details which
might explain where I'm coming from/where the misunderstanding was
(repeating here for posterity in case anyone was curious):

My thinking was that the frontend could be modified to only emit the
bounds when they were non-default (for the lower bound) and bounded
(for the upper bound). Their absence would represent those other
(default/unbounded) states. Then the backend would just always emit a
bound that was specified and omit unspecified bounds thus implementing
the minimal dwarf (& possibly minimal LLVM IR too).

There's a few problems with this:
1) the LLVM metadata schema is typed but not named/structured, so
having one optional integer in a metadata value is easy (hey, how many
integers are there? N or N - 1? OK, N-1 so we're missing the optional
<blah> field) but any more than one optional field is ambiguous in a
contiguous run of the same type (there is one integer instead of two -
is that the upper bound or the lower bound?)
2) if at some point we want to emit different kinds of debug info,
possibly ones without the exact same defaults as dwarf, we'll want to
have access to the value in the backend and choose whether to emit it
there anyway (otherwise we'd have the front ends choosing to drop it
if it's the default, then the backend having to have the logic to
recompute it when it was absent anyway)

- David



More information about the llvm-commits mailing list