FS#70879 - [gdb] gdbserver segfaults with all 32bit apps
Attached to Project:
Arch Linux
Opened by Emil (xexaxo) - Saturday, 15 May 2021, 12:57 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 02 June 2021, 17:54 GMT
Opened by Emil (xexaxo) - Saturday, 15 May 2021, 12:57 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 02 June 2021, 17:54 GMT
|
Details
Description:
Gdbserver does not work with any 32bit app when kernel v5.9+ is used. Even a dummy "int main (void) { return 0; }" fails. Fixed upstream, but never ported to their stable branch. Using the patch for a couple of days without any side-effects. Shout out to simark1 from #gdb for the help o/ Additional info: * package version(s) gdb 10.2-1 * link to upstream bug report, if any https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff_plain;h=037e8112b9794a633248e5aa5943f3be273e0a20 Steps to reproduce: $ gdbserver localhost:12345 glxgears32 $ gdb -batch -q -ex "target remote localhost:12345" -ex continue Program received signal SIGSEGV, Segmentation fault. NOTE: the segfault backtrace varies across applications |
This task depends upon
Closed by Andreas Radke (AndyRTR)
Wednesday, 02 June 2021, 17:54 GMT
Reason for closing: Fixed
Additional comments about closing: gdb-10.2-2
Wednesday, 02 June 2021, 17:54 GMT
Reason for closing: Fixed
Additional comments about closing: gdb-10.2-2
https://sourceware.org/pipermail/gdb/2021-May/049436.html
```
diff --cc gdbserver/linux-x86-low.cc
index 79284473f14,d3273a18f47..00000000000
--- a/gdbserver/linux-x86-low.cc
+++ b/gdbserver/linux-x86-low.cc
@@@ -414,29 -443,11 +443,28 @@@ x86_fill_gregset (struct regcache *regc
#endif
for (i = 0; i < I386_NUM_REGS; i++)
- collect_register (regcache, i, ((char *) buf) + i386_regmap[i]);
-
- collect_register_by_name (regcache, "orig_eax",
- ((char *) buf) + ORIG_EAX * REGSIZE);
+ collect_register_i386 (regcache, i, ((char *) buf) + i386_regmap[i]);
++<<<<<<< HEAD
+#ifdef __x86_64__
+ /* Sign extend EAX value to avoid potential syscall restart
+ problems.
+
+ See amd64_linux_collect_native_gregset() in gdb/amd64-linux-nat.c
+ for a detailed explanation. */
+ if (register_size (regcache->tdesc, 0) == 4)
+ {
+ void *ptr = ((gdb_byte *) buf
+ + i386_regmap[find_regno (regcache->tdesc, "eax")]);
+
+ *(int64_t *) ptr = *(int32_t *) ptr;
+ }
+#endif
++=======
+ /* Handle ORIG_EAX, which is not in i386_regmap. */
+ collect_register_i386 (regcache, find_regno (regcache->tdesc, "orig_eax"),
+ ((char *) buf) + ORIG_EAX * REGSIZE);
++>>>>>>> 037e8112b97 ([gdb/server] Don't overwrite fs/gs_base with -m32)
}
static void
```
Hopefully I got the correct hunks.
# Code has whilespace code changes (-l flag) and we don't care about the failing Changelog delta (|| true)
patch -p1 -i "$srcdir"/foo.patch || true
Edit: Personally I'd opt for ^^, since there's no point in changing the patch (+ the extra changes are undocumented).
Usually if I have to change things I would:
- use cherry-pick -x - so there's a clear reference about the original commit
- leave the list of conflicting files (in the commit message) and document what was changed
Here is an example: https://cgit.freedesktop.org/mesa/mesa/commit/?h=17.0&id=4242dfa3309dcbe2d39069bb557d8df9640a3564
It might seem like an overkill, but it will help you - any anyone else who follows-up - X weeks/months down the line.
Again, all this can be trivially avoided with the patch line mentioned.
Unrelated: what happened with the mesa 7.11.2 build fixes MR for upstream :-P
Agreed although the downside of suppressing the exit code is even if it fails completely makepkg continues.
Should not be an issue in this case as the patch will be dropped next upstream release.
Will email you about the mesa fixes to keep this FS on topic.