【轻量级 PR】：Fix loongarch linux_iterate_over_regset_sections wrong · Pull Request !22 · src-anolis-os/gdb

修复loongarch架构的gdb会在`gcore`转储时报错问题，以下为排查问题

anolis 仅9.x版本受影响，a23不受影响。

# 已知

loongarch架构的系统中，`gcore`命令用于转储进程，此时`gcore`会挂掉报错，一个断言错误。

```
# top &
# gcore  `pidof top`
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
0x00007ffff36043cc in raise () from /usr/lib64/libc.so.6
../../gdb/linux-tdep.c:1549: internal-error: void linux_collect_regset_section_cb(const char*, int, int, const regset*, const char*, void*): Assertion `supply_size == collect_size' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]

This is a bug, please report it.  For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.

../../gdb/linux-tdep.c:1549: internal-error: void linux_collect_regset_section_cb(const char*, int, int, const regset*, const char*, void*): Assertion `supply_size == collect_size' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
/usr/bin/gcore: 行 96: 721551 已放弃               (核心已转储)"$binary_path/gdb" --nx --batch --readnever -ex "set pagination off" -ex "set height 0" -ex "set width 0" "${dump_all_cmds[@]}" -ex "attach $pid" -ex "gcore $prefix.$pid" -ex detach -ex quit < /dev/null
```

# 抓虫

遇到问题，第一，先复现！

gcore失败问题每次都会精准复现，`gcore`只是一个脚本，会使用`gdb`生成dump转储（参考上面的报错）

gdb附加进程时有时候会先尝试下载这个这个进程动态库的debug文件，此机器不联网，会很长时间停在下载的时候，不过没关系，`ctrl + c`可以取消下载，而且发现，`gcore`命令第一次时gdb会下载，较短的时间内在执行gcore就不会下载了，很快就报错了，这样就扫清了障碍。

参考上面报错内容，`gcore`使用了下面的命令生成转储文件，这个命令不能直接执行，猜测是gcore还有其他动作，也就是说，复现也必须用gcore命令操作。

```
gdb --nx --batch --readnever -ex "set pagination off" -ex "set height 0" -ex "set width 0" "${dump_all_cmds[@]}" -ex "attach $pid" -ex "gcore $prefix.$pid" -ex detach -ex quit
```

是gdb报错，需要附加到gdb中。所以，做一个跳板：

```
#!/bin/env python3
import os
import sys
import time

with open("/dev/pts/13", "w") as f:
    f.write("%d" % os.getpid())
time.sleep(10)

os.execve("/usr/libexec/gdb", sys.argv, os.environ)
```

上面的步骤中，`/dev/pts/13`是另一个终端，要把gdb的pid发送到另一个终端中，方便另一个终端中使用gdb附加到这个出错的gdb中。
然后`sleep(10)`为了留出时间附加，在接下来`execve`将会将这个跳板替换为真正的`gdb`程序

接下来，替换这个脚本到`/bin/gdb`，`/bin/gdb`本身也只是一个软连接，指向的是`/usr/libexec/gdb`，另一个终端等待收到gdb的pid进行附加

附加到gdb，`continue`直接就到出错的地方，敲一个`bt`看一下栈

```
# gdb -p <pid of gdb>
(gdb) c
(gdb) bt
#0  0x00007ffff2f1c3f0 in raise () from /usr/lib64/libc.so.6
#1  0x00007ffff2f083f0 in abort () from /usr/lib64/libc.so.6
#2  0x00005555588a37c4 in dump_core () at ../../gdb/utils.c:210
#3  0x00005555588a9238 in internal_vproblem (problem=problem@entry=0x555558dab770 <internal_error_problem>, 
    file=file@entry=0x555558ab07f8 "../../gdb/linux-tdep.c", line=<optimized out>, fmt=<optimized out>, 
    ap=ap@entry=0x7ffffb7ffa28) at ../../gdb/utils.c:420
#4  0x00005555588a93d4 in internal_verror (file=file@entry=0x555558ab07f8 "../../gdb/linux-tdep.c", line=<optimized out>, 
    fmt=<optimized out>, ap=ap@entry=0x7ffffb7ffa28) at ../../gdb/utils.c:445
#5  0x000055555861d14c in internal_error (file=file@entry=0x555558ab07f8 "../../gdb/linux-tdep.c", line=line@entry=1549, 
    fmt=<optimized out>) at ../../gdb/gdbsupport/errors.c:55
#6  0x000055555869af88 in linux_collect_regset_section_cb (sect_name=0x555558a10258 ".reg2", supply_size=<optimized out>, 
    collect_size=<optimized out>, regset=0x555558cee1e0 <loongarch_elf_gregset>, human_name=<optimized out>, 
    cb_data=0x7ffffb7ffb10) at ../../gdb/linux-tdep.c:1574
#7  0x00005555586a80a0 in loongarch_linux_iterate_over_regset_sections (gdbarch=<optimized out>, 
    cb=0x55555869adb0 <linux_collect_regset_section_cb(char const*, int, int, regset const*, char const*, void*)>, 
    cb_data=0x7ffffb7ffb10, regcache=<optimized out>) at ../../gdb/loongarch-linux-tdep.c:299
#8  0x000055555869cbf4 in linux_collect_thread_registers (stop_signal=GDB_SIGNAL_0, note_size=0x7ffffb7ffec4, 
    note_data=0x55556ad96b60 "\206\301\217?PU", obfd=0x55556b029f20, regcache=0x55556acb2c00, ptid=...)
    at ../../gdb/linux-tdep.c:1602
#9  linux_corefile_thread (info=info@entry=0x55556ac60420, args=args@entry=0x7ffffb7ffc20) at ../../gdb/linux-tdep.c:1660
#10 0x000055555869d990 in linux_make_corefile_notes (gdbarch=0x55556acd0380, obfd=0x55556b029f20, note_size=0x7ffffb7ffec4)
    at ../../gdb/linux-tdep.c:1919
#11 0x00005555586077f0 in write_gcore_file_1 (obfd=0x55556b029f20) at ../../gdb/gcore.c:83
#12 write_gcore_file (obfd=0x55556b029f20) at ../../gdb/gcore.c:120
#13 0x00005555586078d8 in gcore_command (args=<optimized out>, from_tty=<optimized out>) at ../../gdb/gcore.c:155
#14 0x000055555853fcec in cmd_func (cmd=<optimized out>, args=<optimized out>, from_tty=<optimized out>)
    at ../../gdb/cli/cli-decode.c:1952
#15 0x0000555558865264 in execute_command (p=<optimized out>, from_tty=<optimized out>) at ../../gdb/top.c:652
#16 0x00005555586b8850 in catch_command_errors (command=command@entry=0x555558864e30 <execute_command(char const*, int)>, 
    arg=<optimized out>, from_tty=<optimized out>) at ../../gdb/main.c:400
#17 0x00005555586ba288 in captured_main_1 (context=<optimized out>) at ../../gdb/main.c:1213
#18 0x00005555586baa04 in captured_main (data=<optimized out>) at ../../gdb/main.c:1263
#19 gdb_main (args=<optimized out>) at ../../gdb/main.c:1263
#20 0x00005555584843bc in main (argc=<optimized out>, argv=<optimized out>) at ../../gdb/gdb.c:40
```

`#6`的位置就是出错的位置，来自于下面的断言：

```
gdb-9.2/gdb/linux-tdep.c: 1538

static void
linux_collect_regset_section_cb (const char *sect_name, int supply_size,
				 int collect_size, const struct regset *regset,
				 const char *human_name, void *cb_data)
{
  if (!variable_size_section)
    gdb_assert (supply_size == collect_size);
```

`#7`的位置指向是这里的第二个`cb`执行的时候的`#6`的函数

```
gdb-9.2/gdb/loongarch-linux-tdep.c: 288

static void
loongarch_linux_iterate_over_regset_sections (struct gdbarch *gdbarch,
					      iterate_over_regset_sections_cb *cb,
					      void *cb_data,
					      const struct regcache *regcache)
{
  auto regs = &gdbarch_tdep (gdbarch)->regs;

if (0 <= regs->r)
    cb (".reg", sizeof (loongarch_elf_gregset_t),
	sizeof (loongarch_elf_gregset_t), &loongarch_elf_gregset, NULL, cb_data);
  if (0 <= regs->f)
    cb (".reg2", sizeof (loongarch_elf_fpregset_t),
	sizeof (loongarch_elf_gregset_t), &loongarch_elf_gregset, NULL, cb_data);
}
```

虽然这里看不懂这里处理的是什么，猜测是`loongarch`架构的寄存器属性的问题，但是，貌似有个地方拼错了。。。

参考下面龙芯的代码，上面的第二个`cb`里的寄存器，应该指的是`fpu`，貌似是龙芯的人员粘贴复制，把上面的部分粘贴过来没改全。。。

```
gdb-9.2/gdb/loongarch-linux-tdep.c: 335

fpu64 = !!bfd_get_section_by_name (abfd, ".reg2");
```

包括其他架构，也有类似的地方：

```
gdb-9.2/gdb/aarch64-linux-tdep.c: 624

cb (".reg2", AARCH64_LINUX_SIZEOF_FPREGSET, AARCH64_LINUX_SIZEOF_FPREGSET,
	&aarch64_linux_fpregset, NULL, cb_data);

gdb-9.2/gdb/alpha-linux-tdep.c: 237

cb (".reg2", 32 * 8, 32 * 8, &alpha_linux_fpregset, NULL, cb_data);
```

所以，应该这样。。。

```
-	sizeof (loongarch_elf_gregset_t), &loongarch_elf_gregset, NULL, cb_data);
+	sizeof (loongarch_elf_fpregset_t), &loongarch_elf_fpregset, NULL, cb_data);
```

改好后验证一下，没问题了。。。。

```
# gcore  `pidof top`
Saved corefile core.719462
```

捡个小漏，并不能看懂这里要处理什么，只是一次下注意到，这个地方好像粘贴复制了没改好。。。

`anolis`和`openEuler`的旧版本`gdb`的`loongarch`支持都是同一个人提交的pr，但是`openeuler`就没问题，`anolis`的有问题，甚至是`openeuler`的`pr`更早。。。

2022年07月13日
[anolis: Add LoongArch support](https://gitee.com/src-anolis-os/gdb/commit/ada61cdb1f8aae8ca0a7a935baece7d37d14a140)

2022-03-30 09:18，该pr更早虽未合并，无错误
[openEuler: Add LoongArch gdb supportt](https://gitee.com/src-openeuler/gdb/pulls/46/commits)

src-anolis-os/gdb .gitee-modal { width: 500px !important; }

搜索帮助

src-anolis-os/gdb