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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D68465#1703341 <https://reviews.llvm.org/D68465#1703341>, @dstenb wrote:

> In D68465#1698682 <https://reviews.llvm.org/D68465#1698682>, @dblaikie wrote:
>
> > So your changes to the address pool don't actually cause the address pool to contain entries with offsets - it stores only the base address in the actual debug_addr pool output, but then uses the offset from there in the place that refers to the address pool.
>
>
> The offset will make it into the address pool output. In the parent patch (D68466 <https://reviews.llvm.org/D68466>) the offset is added to the output in `AddressPool::emit()`.
>
> Such a case is tested in the attached call-clobbered-split.mir test:
>
>   # CHECK: .Ldebug_loc0:
>   [...]
>   # CHECK-NEXT:    .byte    3
>   # CHECK-NEXT:    .byte    2 <---------
>   # CHECK-NEXT:    .long    .Ltmp2-(.Ltmp2-1)
>   # CHECK-NEXT:    .byte    4                       # Loc expr size
>   # CHECK-NEXT:    .byte    48                      # DW_OP_lit0
>   # CHECK-NEXT:    .byte    159                     # DW_OP_stack_value
>   # CHECK-NEXT:    .byte    147                     # DW_OP_piece
>   # CHECK-NEXT:    .byte    8                       # 8
>   [...]
>   # CHECK: .Laddr_table_base0:
>   # CHECK-NEXT:    .quad    .Lfunc_begin0
>   # CHECK-NEXT:    .quad    .Ltmp1
>   # CHECK-NEXT:    .quad    .Ltmp2-1 <-----
>   # CHECK-NEXT:    .quad    .Ltmp2
>


Ah, OK. I haven't applied/tested the patch myself - I looked at GCC's behavior & figured you were probably aiming for the same as it, and it doesn't look like GCC does this - and I'd certainly like to avoid that if at all possible. (though all this is pending discussion/conclusions you get from discussing things with GDB)

>> So I think that would mean there would end up with duplicate entries in debug_addr, which would be a waste of space/relocations/etc.
>> 
>> So only the address should go in the pool - the pool shouldn't be aware of the offset. (this would mean the semantics of the in-memory data structures would match more closely to the output)
> 
> I think it's necessary to emit the offsets in the address pool output since `DW_LLE_offset_pair` takes unsigned operands.

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.


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

https://reviews.llvm.org/D68465