The buildroot cross-compile of gdb with uclibc fails for 11.1 since commit 4655f8509fd44e6efabefa373650d9982ff37fd6 ([1]), see [2] for details: ../../gdbserver/../gdb/nat/linux-personality.c: In constructor ‘maybe_disable_address_space_randomization::maybe_disable_address_space_randomization(int)’: ../../gdbserver/../gdb/nat/linux-personality.c:36:48: error: ‘ADDR_NO_RANDOMIZE’ was not declared in this scope 36 | if (errno == 0 && !(m_personality_orig & ADDR_NO_RANDOMIZE)) | ^~~~~~~~~~~~~~~~~ ../../gdbserver/../gdb/nat/linux-personality.c:42:37: error: ‘ADDR_NO_RANDOMIZE’ was not declared in this scope 42 | && !(personality (0xffffffff) & ADDR_NO_RANDOMIZE))) | ^~~~~~~~~~~~~~~~~ From the commit changelog: [...] If for some odd reason, some remotely modern system still needs a configure check, then we can revert this commit but drop the AC_RUN_IFELSE in favor of always doing the AC_LINK_IFELSE cross-compile fallback. [...] [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=4655f8509fd44e6efabefa373650d9982ff37fd6 [2] http://lists.busybox.net/pipermail/buildroot/2021-November/627651.html
So, the issue is just that the uclibc libc did not have an ADDR_NO_RANDOMIZE value. But all the kernels it runs on presumably do support that personality call. So we could just define the value in our code ourselves. Unfortunately, it is not exposed as a macro, so it's not as simple as: #if !defined(ADDR_NO_RANDOMIZE) # define ADDR_NO_RANDOMIZE ... #endif So we could add back an AC_COMPILE_IFELSE configure test to see if the value is provided by the system, and we could define it ourselves otherwise. Or simpler, since this value is not likely to change ever, would be to just do: #define GDB_ADDR_NO_RANDOMIZE 0x0040000 and use that. In the mean time, I see that Thomas (from Buildroot) has patched uclibc to add the ADDR_NO_RANDOMIZE value, so future releases / deployments will include it: https://repo.or.cz/uclibc-ng.git/commit/85ac4f04d94e98389a8315e720630d0f95bfdfd6 I have also tried to change the code to include the Linux kernel-provided header <linux/personality.h>, but that does not work. If I include it instead of <sys/personality.h>, then the code doesn't see the personality function that wraps the syscall (provided by the libc). If I include it in addition to <sys/personality.h>, then there are duplicate enum definitions.
Tromey also ran into something similar on RH ES5: https://sourceware.org/pipermail/gdb-patches/2021-May/178801.html > Or simpler, since this value is not likely to change ever, would be to just do: > #define GDB_ADDR_NO_RANDOMIZE 0x0040000 > and use that. That seems fine to me. This value isn't going to ever change since changing it would be an ABI break. The actual trouble would be if different architectures defined the constant differently, which I don't think is the case. I have no idea whether uclibc users are able to build unpatched gdb, or if the uclibc project carries some local patches. If the latter, maybe we can just ignore this since it's been fixed for the next release.
> I have no idea whether uclibc users are able to build unpatched gdb, or if > the uclibc project carries some local patches. If the latter, maybe we can > just ignore this since it's been fixed for the next release. Buildroot can carry a local GDB patch, but it doesn't really make sense for uclibc (or I don't understand what you mean). The idea would be to change GDB to have it build on existing uclibc systems, because the change in uclibc will take some time to reach users.
(In reply to Pedro Alves from comment #2) > Tromey also ran into something similar on RH ES5: > > https://sourceware.org/pipermail/gdb-patches/2021-May/178801.html I can send the full patch if someone wants it, just let me know.
(In reply to Tom Tromey from comment #4) > (In reply to Pedro Alves from comment #2) > > Tromey also ran into something similar on RH ES5: > > > > https://sourceware.org/pipermail/gdb-patches/2021-May/178801.html > > I can send the full patch if someone wants it, just let me know. The patch you describe sounds like what I suggested above, so if you can send it, I think we can merge it without much effort.
https://sourceware.org/pipermail/gdb-patches/2021-November/183256.html
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0b03c6f03d51f441d999e0cee92f81af543d9373 commit 0b03c6f03d51f441d999e0cee92f81af543d9373 Author: Tom Tromey <tromey@adacore.com> Date: Wed May 12 12:39:22 2021 -0600 Fix build on rhES5 The rhES5 build failed due to an upstream import a while back. The bug here is that, while the 'personality' function exists, ADDR_NO_RANDOMIZE is only defined in <linux/personality.h>, not <sys/personality.h>. However, <linux/personality.h> does not declare the 'personality' function, and <sys/personality.h> and <linux/personality.h> cannot both be included. This patch restores one of the removed configure checks and updates the code to check it. We had this as a local patch at AdaCore, because it seemed like there was no interest upstream. However, now it turns out that this fixes PR build/28555, so I'm sending it now.
I think this is fixed on trunk now. Can you try it? If it works, I can backport the fix to the gdb 11 branch.
(In reply to Tom Tromey from comment #8) > I think this is fixed on trunk now. > Can you try it? If it works, I can backport the fix to the gdb 11 branch. Thanks for the fix, works for the buildroot use case (with pre-build toolchain using an version of uclibc-ng predating the mentioned fix) too (see [1] for details)... [1] http://lists.busybox.net/pipermail/buildroot/2021-November/628266.html
The gdb-11-branch branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=df9ebc472a162306dee8ba6e02b99963c2babb7c commit df9ebc472a162306dee8ba6e02b99963c2babb7c Author: Tom Tromey <tromey@adacore.com> Date: Wed May 12 12:39:22 2021 -0600 Fix build on rhES5 The rhES5 build failed due to an upstream import a while back. The bug here is that, while the 'personality' function exists, ADDR_NO_RANDOMIZE is only defined in <linux/personality.h>, not <sys/personality.h>. However, <linux/personality.h> does not declare the 'personality' function, and <sys/personality.h> and <linux/personality.h> cannot both be included. This patch restores one of the removed configure checks and updates the code to check it. We had this as a local patch at AdaCore, because it seemed like there was no interest upstream. However, now it turns out that this fixes PR build/28555, so I'm sending it now.
Fixed on the branch now too.