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

[David Stenberg via Phabricator via llvm-commits]

dstenb added a comment.

In D68465#1704522 <https://reviews.llvm.org/D68465#1704522>, @dblaikie wrote:

> Unsigned operands don't /seem/ to me to be problematic here..
>
> GCC's output in -gdwarf-5 with the example you provided previously doesn't use debug_addr, instead using offset_pair (if there's a base address) or start_length (if I add another function to the example, and use -ffunction-sections, so the base address of the CU is constant zero):
>
>   .byte   0x8
>   .quad   .LVL0
>   .uleb128 .LVL1-1-.LVL0
>   .uleb128 0x1
>   .byte   0x50
>   .byte   0
>   
>
> With -gsplit-dwarf GCC has to use debug_addr, and we don't see any label arithmetic in debug_addr:
>
>   .section        .debug_addr,"", at progbits
>   .quad   .LVL1
>   .quad   .LFB0
>   .quad   .LFB1
>   .quad   call
>   .quad   value
>   .quad   .LVL0
>   
>
> & we do see it in debug_loclists.dwo:
>
>   .byte   0x3
>   .uleb128 0x5
>   .uleb128 .LVL1-1-.LVL0
>   .uleb128 0x1
>   .byte   0x50
>   .byte   0
>   
>
> So if we are going to do this, I'd certainly want to match that sort of behavior - and not make changes to/add extra addresses to debug_addr if we don't have to.


Is that output based on the C reproducer I posted a few comments up? 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.


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

https://reviews.llvm.org/D68465