[PATCH] D68465: [DebugInfo] Trim call-clobbered location list entries when tuning for GDB

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

> I don't think that case is representative for the issue with the offsets in the address pool. Since the variable is only described by a call-clobbered register, we only have to end a location list entry at `$return_addr - 1`, not start a location list entry at `$return_addr - 1`. I think we can get away without needing offsets in the address pool for such cases.
> 
> The C reproducer that the call-clobbered-split.mir test case is based on has an aggregate variable whose elements are described by a call-clobbered register respectively a constant, so we want to start a location list entry at `$return_addr - 1` for which only the constant element is described.
> 
> Here is that C reproducer:
> 
>   extern void fn2(int *);
>   
>   void fn1() {
>     int data[] = {1, 2};
>     int *ptrs[] = {0, &data[1]};
>     fn2(ptrs[1]);
>     ptrs[1] = 0;
>   }
> 
> 
> If I compile that with GCC 7.4.0 using the following command line:
> 
>   $ gcc-7 -O1 -g -gdwarf-5 -gsplit-dwarf -S -o - foo.c
> 
> 
> GCC emits an address pool entry with an offset:
> 
>   [...]
>   .Ldebug_addr0:
>           .quad   .LVL1
>           .quad   .LVL2
>           .quad   .LVL3
>           .quad   .LFB0
>           .quad   .LVL2-1 <----------
>           .quad   fn2
>           .quad   __stack_chk_fail
>           .quad   .LVL0
> 
> 
> So this patch seems to behave similarly as, admittedly a quite old version of, GCC. I'll build the latest GCC release and try the same with that.

Yeah, GCC 8.1 has the same behavior.

But I think we can avoid that in LLVM with some of the loclist changes I'm working on - we should only ever be using the start of a function (not necessarily the current function, if there are multiple functions in the same section) as a base address in location lists. So locations like this should be rendered as offset pairs relative to that base address & should always be positive, even if you subtract 1.

I'm wondering whether it might be worth deferring all this design discussion until after there's more clarity from GDB - since I expect that's the right path forward & this design discussion may be unnecessary.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68465/new/

https://reviews.llvm.org/D68465