[llvm] r235050 - DebugInfo: Remove 'inlinedAt:' field from MDLocalVariable

[Robinson, Paul]

> > I imagine if [debug_loc] is produced for two distinct inlined variables
> > (from distinct inlined calls to the same function) then their location
> lists
> > might end up accidentally shared (they'd end up with the same location
> list
> > (possibly combining both variable location lists), rather than distinct
> > ones)?
> >
> > The instruction-address ranges for the two instances of the variable
> will be
> > different, therefore the location lists will be different.  I can't
> imagine
> > any scenario where location lists could be shared.
> 
> Sorry, I was describing a possible outcome of a bug Duncan had located
> in his recent changes (to help him formulate a test/observable change
> when he fixes that bug), not proposing a correct way that LLVM should
> behave.

Ah okay. If I'd read the thread more closely instead of skimming I should
have figured that out.  Sorry for the noise.
--paulr

> 
> - David
> 
> >
> > --paulr
> >
> >
> >
> > From: llvm-commits-bounces at cs.uiuc.edu
> > [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of David Blaikie
> > Sent: Thursday, April 16, 2015 3:50 PM
> > To: Duncan P. N. Exon Smith
> > Cc: llvm-commits at cs.uiuc.edu
> > Subject: Re: [llvm] r235050 - DebugInfo: Remove 'inlinedAt:' field from
> > MDLocalVariable
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Apr 16, 2015 at 3:37 PM, Duncan P. N. Exon Smith
> > <dexonsmith at apple.com> wrote:
> >
> >
> >> On 2015-Apr-16, at 14:21, Duncan P. N. Exon Smith
> <dexonsmith at apple.com>
> >> wrote:
> >>
> >>>
> >>> On 2015-Apr-16, at 11:41, David Blaikie <dblaikie at gmail.com> wrote:
> >>>
> >>> (from IRC discussion)
> >>>
> >>> Looks like this might've caused the GDB buildbot regression seen here:
> >>> http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-
> 75/builds/21390
> >>>
> >>> Specifically, in the below program
> >>>
> >>> int *g;
> >>>
> >>> static __attribute__((always_inline)) int f(int a) {
> >>>  int l;
> >>>  g = &l;
> >>>  return a;
> >>> }
> >>>
> >>> int main(void) {
> >>>  f(0);
> >>>  f(0);
> >>>  return 0;
> >>> }
> >>>
> >>> The inlined_subroutine for 'f' in 'main' has no
> DW_TAG_formal_parameter
> >>> (for 'a')
> >>
> >> I've tracked this down -- UserValue::match() needed to be updated.
> >
> > r235140
> >
> >>
> >> I fixed what might be an unrelated bug in DebugLocEntry.  I'll have
> >> to separate out the two changes to see if this testcase provides any
> >> coverage for `DebugLocEntry`; if not I'll maybe need some help from
> >> you or Adrian coming up with a good testcase for that one.
> >
> > This turned out to be unrelated.
> >
> > Looking at the code, I'm not even sure what the variables are doing in
> > `DebugLocEntry` -- they're only used to prevent adjacent locations from
> > coalescing.  I guess the main problem is I don't know what this table is
> > for (well, `.debug_loc`, but I don't know what that is either).
> >
> >
> > .debug_loc is for variables that don't reside in just a single location
> for
> > their entire lifetime (much like debug_ranges discussed earlier) - if a
> > variable resides in a single place for its entire scope, then
> DW_AT_location
> > will have a dwarf expression describing that location, otherwise it'll
> have
> > a sec_offset/data4 giving the offset in debug_loc that describes the
> various
> > locations and ranges for the variable.
> >
> > You might look for existing test cases that produce debug_loc sections?
> But
> > I don't have a canonical way to produce one off-hand. I imagine if one
> is
> > produced for two distinct inlined variables (from distinct inlined calls
> to
> > the same function) then their location lists might end up accidentally
> > shared (they'd end up with the same location list (possibly combining
> both
> > variable location lists), rather than distinct ones)?
> >
> >
> >
> > By inspection, r235050 caused a behaviour change here (and the attached
> > patch would revert the behaviour change), but I honestly have no idea
> > what to test.
> >
> > Adrian, you seem to have touched this code most recently.  Any ideas?
> >
> >