[PATCH] D7895: Anonymous namespaces are missing import DW_TAG_imported_module.

Tue Aug 18 11:05:37 PDT 2015

On Tue, Aug 18, 2015 at 11:03 AM David Blaikie <dblaikie at gmail.com> wrote:

> On Tue, Aug 18, 2015 at 10:59 AM, Eric Christopher <echristo at gmail.com>
> wrote:
>
>>
>>
>> On Tue, Aug 18, 2015 at 10:55 AM David Blaikie <dblaikie at gmail.com>
>> wrote:
>>
>>> On Tue, Aug 18, 2015 at 10:43 AM, Robinson, Paul <
>>> Paul_Robinson at playstation.sony.com> wrote:
>>>
>>>> The as-if suggests that an explicit artificial import is an entirely
>>>> appropriate, natural and good way to handle it, because it models the
>>>> language behavior exactly without *requiring* additional smarts on the
>>>> debugger side.
>>>>
>>>
>>> I agree it is a way to handle it - but I don't understand why "without
>>> requiring* additional smarts on the debugger side" is a goal.
>>>
>>>
>> That said, it seems to be a bit of a double standard here. We require
>> lots of additional smarts on the debugger side to deal with ABI knowledge,
>> and in fact have numerous odd workarounds in DWARF to deal with parameter
>> passing that would be less of an issue if we had generalized ABI support
>> (as an example). How is this case any different?
>>
>
> The conclusion with the ABI stuff was that it would be impossible for a
> client to model it correctly - there were cases Richard demonstrated that
> there was no reasonable extra DWARF we could produce in the type that would
> allow the debugger to make the right choice about the calling convention to
> use when that type was passed (I believe there were particular template
> cases?). Also, the argument was made that these rules change over time -
> and the debugger wouldn't know which set of rules to use without being told
> which ones the compiler had used when it compiled this file (OK, so if we
> had enough type information, we could've just put a "ABI rev number" on the
> CU).
>
> For both of those reasons, it is necessary that we actually just put a tag
> on the type specifying how it should be passed.
>
>
Or specify ABI per function of course.

> These cases don't apply here - C++ has fun/weird/interesting name lookup
> rules (and, admittedly, I'd wager we still don't provide enough DWARF to
> make the name lookup work every time (SFINAE being an obvious example of
> happy fun times), but generally we rely on consumers to do best effort
> rather than by trying to describe it all explicitly in DWARF - the latter
> seems pretty much impractical)
>
>
Oh I agree. :)

-eric

> - Dave
>
>
>>
>> -eric
>>
>>
>>> natural/good - I just don't agree with. The stated goal in many cases
>>> has been that the DWARF model the source as written. This is a case where
>>> that's easy and obvious to do.
>>>
>>> * it's not requiring - it's just a degraded experience (as you say,
>>> quality of implementation - as with many places where, if the debugger
>>> doesn't understand C++, it gets a less-than-ideal user experience)
>>>
>>>
>>>> Not all as-if statements have to be modeled directly in the DWARF,
>>>> because they aren't relevant to DWARF or DWARF has other ways of achieving
>>>> the same effect.  For example, [namespace.udir]/2 says a using-directive
>>>> means "the names appear * as if *they were declared in the nearest
>>>> enclosing namespace…" but there's no reason to generate piles of
>>>> declarations in the outer namespace because, we have DW_TAG_imported_module
>>>> which means exactly that.
>>>>
>>>> I don't see any good reason for artificial namespaces to be treated
>>>> specially just because the namespace is anonymous and the 'using' directive
>>>> isn't explicit in the source.
>>>>
>>>
>>> From my perspective it seems like you're asking the producer to special
>>> case anonymous namespaces so the debugger doesn't have to. I'd simply argue
>>> the opposite - I'd like to not special case them in the producer, instead
>>> producing source-accurate debug info as much as possible, and leave it to
>>> the debugger to implement appropriate behavior.
>>>
>>> The Cobol example seems perfect: We rely on consumers modeling languages
>>> correctly to import outer namespaces into inner ones in languages that
>>> support that. In the languages that don't, we rely on the consumer to know
>>> that and model it differently. If a consumer does not do this, the user
>>> gets a degraded experience (their cobol name lookup is wrong (or perhaps
>>> their non-cobol name lookup is wrong, if the debugger decided to only model
>>> the cobol side and assume all other languages work that way too)).
>>>
>>> This seems directly analogous to anonymous namespaces - we describe the
>>> source and let the consumer model it appropriately.
>>>
>>>
>>>> --paulr
>>>>
>>>>
>>>>
>>>> *From:* David Blaikie [mailto:dblaikie at gmail.com]
>>>> *Sent:* Tuesday, August 18, 2015 10:27 AM
>>>> *To:* Robinson, Paul
>>>> *Cc:* reviews+D7895+public+7827be49c0b04087 at reviews.llvm.org;
>>>> Romanova, Katya; Eric Christopher; Frédéric Riss; Duncan P. N. Exon Smith;
>>>> llvm-commits
>>>> *Subject:* Re: [PATCH] D7895: Anonymous namespaces are missing import
>>>> DW_TAG_imported_module.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Aug 18, 2015 at 10:23 AM, Robinson, Paul <
>>>> Paul_Robinson at playstation.sony.com> wrote:
>>>>
>>>> | suggests that DW_TAG_imported_module could be used for C++ using
>>>> directives (of which there are none in the source code in question).
>>>>
>>>>
>>>>
>>>> [namespace.unnamed]/1 says there is an implicit (as-if) using directive.
>>>>
>>>>
>>>>
>>>> Lots of things are as-if, doesn't mean we model them in the DWARF that
>>>> way, it's just an easy way of defining the behavior in terms of other stuff
>>>> that's already defined in the standard. Generally we try to model things
>>>> like the actual source where possible, it seems/usually sounds like/etc.
>>>>
>>>>
>>>>
>>>> --paulr
>>>>
>>>>
>>>>
>>>> *From:* David Blaikie [mailto:dblaikie at gmail.com]
>>>> *Sent:* Tuesday, August 18, 2015 10:15 AM
>>>>
>>>>
>>>> *To:* Robinson, Paul
>>>> *Cc:* reviews+D7895+public+7827be49c0b04087 at reviews.llvm.org;
>>>> Romanova, Katya; Eric Christopher; Frédéric Riss; Duncan P. N. Exon Smith;
>>>> llvm-commits
>>>> *Subject:* Re: [PATCH] D7895: Anonymous namespaces are missing import
>>>> DW_TAG_imported_module.
>>>>
>>>>
>>>>
>>>> All I'm saying is that I think this is a fine thing to have as a
>>>> debugger-specific tuning for your debugger.
>>>>
>>>> DWARF-the-standard is language neutral, yes, so it provides features
>>>> that can be used to describe many different languages. It describes
>>>> (non-normatively) possible uses of DWARF features for language features,
>>>> and suggests that DW_TAG_imported_module could be used for C++ using
>>>> directives (of which there are none in the source code in question). It
>>>> doesn't suggest anywhere that it should, let alone must, be used to
>>>> explicitly describe name lookup rules (or we'd need those using directives
>>>> in nested scopes for all outer scopes, for example).
>>>>
>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150818/dc96395c/attachment.html>