[LoongArch] Add debug location for register reload

[wangleiat]

Although the automatically inserted reload instruction in the Epilogue
is unrelated to the original code, in order to improve debugger
functionality, we have re-added debugging location information in the
reload instruction. When using an empty debugging location, the
following issue occurs:

loongson@linux:~$ cat -n test.c
 1  int printf(const char *, ...);
 2  int main(int argc, char **argv) {
 3    printf("%d\n", argc);
 4    return 0;
 5  }
 clang -g -O0 test.c -o test

Without this patch, the debugger is unable to correctly access the
current stack information when a breakpoint is set on line 4:

loongson@linux:~$ gdb -q ./test
Reading symbols from ./test...
(gdb) break 4
Breakpoint 1 at 0x7c0: file test.c, line 4.
(gdb) run
Starting program: /home/wanglei/test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/loongarch64-linux-gnu/libthread_db.so.1".
1

Breakpoint 1, main (argc=<error reading variable: Cannot access memory at address 0xffffffffffffffe8>,
    argv=<error reading variable: Cannot access memory at address 0xffffffffffffffe0>) at test.c:4
4         return 0;

[llvmbot]

@llvm/pr-subscribers-backend-loongarch

Author: wanglei (wangleiat)

Changes

Although the automatically inserted reload instruction in the Epilogue
is unrelated to the original code, in order to improve debugger
functionality, we have re-added debugging location information in the
reload instruction. When using an empty debugging location, the
following issue occurs:

loongson@<!-- -->linux:~$ cat -n test.c
 1  int printf(const char *, ...);
 2  int main(int argc, char **argv) {
 3    printf("%d\n", argc);
 4    return 0;
 5  }
 clang -g -O0 test.c -o test

Without this patch, the debugger is unable to correctly access the
current stack information when a breakpoint is set on line 4:

loongson@<!-- -->linux:~$ gdb -q ./test
Reading symbols from ./test...
(gdb) break 4
Breakpoint 1 at 0x7c0: file test.c, line 4.
(gdb) run
Starting program: /home/wanglei/test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/loongarch64-linux-gnu/libthread_db.so.1".
1

Breakpoint 1, main (argc=&lt;error reading variable: Cannot access memory at address 0xffffffffffffffe8&gt;,
    argv=&lt;error reading variable: Cannot access memory at address 0xffffffffffffffe0&gt;) at test.c:4
4         return 0;

---

Full diff: https://github.com/llvm/llvm-project/pull/122057.diff

1 Files Affected:

• (modified) llvm/lib/Target/LoongArch/LoongArchInstrInfo.cpp (+4-1)

diff --git a/llvm/lib/Target/LoongArch/LoongArchInstrInfo.cpp b/llvm/lib/Target/LoongArch/LoongArchInstrInfo.cpp
index 54aeda28364003..32bc8bb8012957 100644
--- a/llvm/lib/Target/LoongArch/LoongArchInstrInfo.cpp
+++ b/llvm/lib/Target/LoongArch/LoongArchInstrInfo.cpp
@@ -154,6 +154,9 @@ void LoongArchInstrInfo::loadRegFromStackSlot(MachineBasicBlock &MBB,
                                               Register VReg) const {
   MachineFunction *MF = MBB.getParent();
   MachineFrameInfo &MFI = MF->getFrameInfo();
+  DebugLoc DL;
+  if (I != MBB.end())
+    DL = I->getDebugLoc();
 
   unsigned Opcode;
   if (LoongArch::GPRRegClass.hasSubClassEq(RC))
@@ -177,7 +180,7 @@ void LoongArchInstrInfo::loadRegFromStackSlot(MachineBasicBlock &MBB,
       MachinePointerInfo::getFixedStack(*MF, FI), MachineMemOperand::MOLoad,
       MFI.getObjectSize(FI), MFI.getObjectAlign(FI));
 
-  BuildMI(MBB, I, DebugLoc(), get(Opcode), DstReg)
+  BuildMI(MBB, I, DL, get(Opcode), DstReg)
       .addFrameIndex(FI)
       .addImm(0)
       .addMemOperand(MMO);

[wangleiat]

@xen0n

[heiher]

Here is another similar issue:

$ gdb ./t
GNU gdb (GDB) 15.1
...
(gdb) b *main
Breakpoint 1 at 0x760: file t.c, line 2.
(gdb) r
...
Breakpoint 1, main (argc=<error reading variable: Cannot access memory at address 0xffffffffffffffe8>, 
    argv=<error reading variable: Cannot access memory at address 0xffffffffffffffe0>) at t.c:2
2	int main(int argc, char **argv) {

[xen0n]

looks fine but I haven't tested

[wangleiat]

Here is another similar issue:

$ gdb ./t
GNU gdb (GDB) 15.1
...
(gdb) b *main
Breakpoint 1 at 0x760: file t.c, line 2.
(gdb) r
...
Breakpoint 1, main (argc=<error reading variable: Cannot access memory at address 0xffffffffffffffe8>, 
    argv=<error reading variable: Cannot access memory at address 0xffffffffffffffe0>) at t.c:2
2	int main(int argc, char **argv) {

This is correct. argc and argv are calculated through fp, where argc = $r22 - 24 and argv = r22 - 32. When breaking at *main, $r22 = 0, and at this point, argc and argv are inaccessible.

[heiher]

Here is another similar issue:

$ gdb ./t
GNU gdb (GDB) 15.1
...
(gdb) b *main
Breakpoint 1 at 0x760: file t.c, line 2.
(gdb) r
...
Breakpoint 1, main (argc=<error reading variable: Cannot access memory at address 0xffffffffffffffe8>, 
    argv=<error reading variable: Cannot access memory at address 0xffffffffffffffe0>) at t.c:2
2	int main(int argc, char **argv) {

This is correct. argc and argv are calculated through fp, where argc = $r22 - 24 and argv = r22 - 32. When breaking at *main, $r22 = 0, and at this point, argc and argv are inaccessible.

I agree. Throwing an inaccessible result is better than GCC displaying the spurious zero value.

Breakpoint 1, main (argc=0, argv=0x0) at t.c:2

[heiher]

LGTM. Thanks.