[llvm-dev] DebugInfo proposal: Emit an explicit empty address range on CUs with no code addresses

[David Blaikie via llvm-dev]

Looks like I argued (& then tested) previously for support for the case
where the CU has no ranges, but sub-DIEs do:
http://lists.llvm.org/pipermail/llvm-dev/2017-November/119131.html

(Just for the record, LLVM gained support for CU ranges were
implemented r197776,
December 2013 (& shortly after that became the default in r203968, March
2014 - in the 3.5 release) - looks like GCC got this somewhere between GCC
4.1 and GCC 4.4 according to godbolt testing, so on/before March 2012 I
think)


So I've gone ahead and committed this change in r349333 - open to further
discussion, reverting it, etc.

- Dave


On Wed, Nov 28, 2018 at 10:48 AM David Blaikie <dblaikie at gmail.com> wrote:

> Yeah, fair - I'll give it a week or something, see if Paul or anyone else
> has ideas about why the existing behavior might be useful before I remove
> it.
>
> On Wed, Nov 28, 2018 at 10:27 AM Adrian Prantl <aprantl at apple.com> wrote:
>
>>
>> On Nov 28, 2018, at 9:50 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>
>> > a) decide that a unit without ranges covers no ranges - and don't do
>>> the search
>>>
>>> Are there compilers that do this ("forget" to emit ranges) that we care
>>> to support with llvm-symbolizer?
>>>
>>
>> I'm not specifically aware of any, though haven't gone looking.
>>
>>
>> Just in case this wasn't obvious in the sub-text:
>> I think we should figure out whether this assumption in llvm-symbolizer
>> is actually needed to support a compiler we care about and then potentially
>> remove it, or enforce it only when the CU is < DWARF 5 or something like
>> that.
>>
>> -- adrian
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181217/fcf1da21/attachment.html>