[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#1695482 <https://reviews.llvm.org/D68465#1695482>, @dblaikie wrote:

> Thanks for bringing this up!
>
> A few thoughts from me:
>
> 1. Yeah, I tend to agree with the DWARF Committee folks & the fact that LLDB can do the right thing without this change sort of points to this being a "fix it in GDB" situation. Have you tried asking the GDB folks about it/submitting patches there rather than here?


No, we have not done that yet.

> 2. Do you have a small example of GCC producing this kind of output?



  extern int value(void);
  extern void call(int);
  
  int main() {
    int local = value();
    call(local);
    return 0;
  }

compiled using -O1 -g with GCC 8.3.0 gives:

  (gdb) info addr local
  Symbol "local" is multi-location:
    Range 0x5555555550ee-0x5555555550f4: a variable in $rax
  .
  (gdb) disas main
  [...]
     0x00005555555550f0 <+11>:	callq  0x5555555550ff <call>
     0x00005555555550f5 <+16>:	mov    $0x0,%eax
  [...]

As seen, the location list entry ends one byte before the return address.

> 3. The ability to use an offset from a debug_addr entry is actually something that's quite desirable - but not quite in the way you're suggesting. Actually the goal would be to not use another debug_addr entry, but the ability to refer to an addr entry + offset in a DIE. Of course this would require an extension to DWARF (non-standard, or eventually standard) which would also mean updating the DWARF consumer... which probably defeats the point of your work, which I imagine is intended to avoid changing the consumer. Though perhaps GDB would be more inclined to accept a patch for an addr+offset form compared to support for the register details.

Okay! How would that look like, and what would that be used for?

> 4. If GDB can do the right thing when printing in a backtrace, then it seems like it should do the same/similar thing when in a frame

The same problem exists for backtraces. For example, in PR39752 the outer frames' parameters are printed using the inner-most register value:

  (gdb) bt
  #0  fn3 (p3=<optimized out>) at test.c:11
  #1  0x000000000040050f in fn2 (p2=999) at test.c:15
  #2  0x000000000040052f in fn1 (p1=999) at test.c:21
  #3  0x000000000040054e in main () at test.c:26




Repository:
  rL LLVM

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

https://reviews.llvm.org/D68465