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

[David Blaikie]

On Thu, Apr 16, 2015 at 6:14 PM, Robinson, Paul
<Paul_Robinson at playstation.sony.com> wrote:
> 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.

- 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?
>
>