[llvm] r207719 - Revert "Emit DW_AT_object_pointer once, on the declaration, for each function."

[Robinson, Paul]

> -----Original Message-----
> From: Eric Christopher [mailto:echristo at gmail.com]
> On Thu, May 1, 2014 at 10:27 AM, David Blaikie <dblaikie at gmail.com>
> wrote:
> > On Thu, May 1, 2014 at 8:50 AM, Robinson, Paul
> > <Paul_Robinson at playstation.sony.com> wrote:
> >>> -----Original Message-----
> >>> From: David Blaikie [mailto:dblaikie at gmail.com]
> >>> On Wed, Apr 30, 2014 at 7:40 PM, Robinson, Paul
> >>> <Paul_Robinson at playstation.sony.com> wrote:
> >>> > Yeah, I was wondering.  Attributes like object_pointer seem more
> >>> > appropriate to a definition than a declaration, as the declaration
> >>> > typically wouldn't provide the actual location.
> >>>
> >>> I'm not sure the actual location is a prerequisite for making use of
> >>> object_pointer - I figured callers might like to know about it (but
> I
> >>> suppose you can't /call/ a function from just the DWARF declaration?
> >>> Never really thought about whether debuggers would manage that -
> they
> >>> could /maybe/ build the mangled name, etc). Useful for rendering
> >>> functions in pretty printers (well, the first parameter is flagged
> as
> >>> artifiical in the declaration, perhaps that's sufficient for
> printing
> >>> purposes - another case where it'd be nice if we didn't have to
> >>> duplicate that information in the definition, though).
> >>>
> >>> But, sure, it'd be great if there was no reason to put
> object_pointer
> >>> on declarations - not insignificant space savings when emitting
> types
> >>> all over the place.
> >>>
> >>> - David
> >>>
> >>> > --paulr
> >>
> >> If you have a definition, then the location is definitely relevant;
> >> a location expression might want to push the object address, and for
> >> that you need to know where the object is!
> >
> > I'm not suggesting it's not helpful at the definition, just that it
> > shouldn't need to be duplicated there.
> >
> >> But if you're inheriting
> >> the object_pointer from the declaration, which only points to the
> >> declaration's formal_parameter, which has no location... not very
> >> helpful.
> >
> > I don't know why an implementation wouldn't derive it from the
> > declaration - they must have the same parameters in the same order,
> > right?
> >
> 
> Exactly.

The declaration and definition have distinct sets of DIEs that describe 
the same parameters in the same order; that by itself *intuitively* 
establishes a correspondence, but there's no direct connection from a
DWARF perspective.

> 
> >> That's why I'd expect the definition to have one, and if
> >> the definition has one, then having one on the declaration is not
> >> necessary.
> >>
> >> If you have a declaration with no definition... I suppose it would
> >> be "for completeness" to have object_pointer point to the 'this'
> >> parameter (in C++) although some debuggers I've worked with are
> >> happy to infer that from the first formal_parameter being named
> >> 'this' and marked artificial.
> >
> > Right - and I assume they'd be able to infer that in the definition
> > too. Evidently GCC doesn't infer it in the definition, nor derive it
> > from the declaration.
> 
> They should be able to, but probably hasn't come up and so it hasn't
> been thought about.
> 
> -eric

The definition's formal_parameter has a location attribute, but the
declaration's object_pointer points to the declaration's formal_parameter
and so won't find the location attribute.  Unless you persuade your
debugger to troll for the corresponding formal_parameter DIEs in the
definition, after finding the object_pointer link to the declaration's
formal_parameter...  This degree of indirect association is not very
DWARF-ish.  The appropriate solution is just to put the object_pointer 
on the definition, and have it directly point to the formal_parameter 
that has the location.  The size cost is small and the links all do
the right thing.
--paulr