[PATCH] DebugInfo: fix crash with null streamer

David Blaikie dblaikie at gmail.com
Sun Jun 22 08:51:14 PDT 2014


On Thu, Jun 19, 2014 at 7:03 PM, Rafael EspĂ­ndola
<rafael.espindola at gmail.com> wrote:
>> With a sufficient change in abstractions it might be possible, though.
>>
>> Here's the issue (vaguely) as I dabbled with this recently: DWARF line
>> table construction is built into the MCStreamer - my understanding is
>> that it needs to be at that layer since that's where relaxation
>> occurs, so the streamer's the only thing that knows literally how many
>> bytes the instruction sequence is (or, in the case of asm output, #
>> line directives have to be interspersed with the instruction stream).
>> I suppose that's the critical thing to your proposal here: to create
>> the line table, information from the MCStreamer is required.
>>
>> This would be fine for your proposal, but for the wrinkle that the
>> rest of DWARF output references the line table too - the files listed
>> in the line table are also referenced from debug info to describe the
>> file location of the various debug info entities (classes, functions,
>> variables, etc). So we need to be able to query for existing file
>> numberings, and/or insert new ones (which might later be reused by the
>> line table data too).
>>
>> That's my rough understanding, anyway.
>
> I think in the end the real fix is to fix pr18716. With that fixed the
> logic for creating ids can go out of the streamer.

I don't believe that would fix this issue - line directives still have
to be handled by the MCStreamer due to relaxation as I understnad it,
so the logic for creating IDs can't be moved out entirely. Well, if
the API to the streamer just dealt with file numbers, imposed from the
caller, is that what you're getting at? Why is that only possible with
the fix to PR18716? (what stops us changing the MCStreamer interface
today to only handle file numbers? I suspect it's the need to handle
the integrated-asm case (ie: just acting as an assembler) but that
could be addressed)

- David




More information about the llvm-commits mailing list