Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: trcrsired <oyzawqgcfc@gmail.com>
To: binutils@sourceware.org
Cc: gdb-patches@sourceware.org
Subject: [PATCH 1/1] Support building binutils-gdb for an Android (bionic) host
Date: Thu, 29 Oct 2026 20:41:17 +0800	[thread overview]
Message-ID: <20261029124117.13519-2-oyzawqgcfc@gmail.com> (raw)
In-Reply-To: <20261029124117.13519-1-oyzawqgcfc@gmail.com>

Building with --host=aarch64-linux-android30 failed because bionic is not
glibc:

- The compiler's <limits.h> does not expose PATH_MAX (bionic defines it in
  <linux/limits.h>), while <sys/param.h> defines MAXPATHLEN as PATH_MAX.
  Make PATH_MAX available from libiberty.h and gnulib's pathmax.h for
  __ANDROID__.
- bionic's <stdint.h> defines UINTPTR_WIDTH in terms of
  __UINTPTR_WIDTH__, which GCC does not predefine.  Derive the width from
  the type in rawmemchr.c.
- bionic's fortify headers do not compile from C++ with the Android GCC
  port, so do not define _FORTIFY_SOURCE for __ANDROID__.
- Modern NDKs provide Elf32_auxv_t/Elf64_auxv_t, so stop assuming Android
  lacks them in gdbserver; linux-low.cc otherwise defines conflicting
  struct tags.
- gprofng needs glibc facilities (pthread cancellation, dlinfo), so do
  not build it for android targets.

	/
	* configure.ac (enable_gprofng): Do not build gprofng for android
	targets.
	* configure: Regenerate.

include/ChangeLog:

	* libiberty.h: Include <linux/limits.h> on Android when PATH_MAX
	is not defined.
---
 configure                 |  2 +-
 configure.ac              |  2 +-
 gdbserver/configure       | 17 +----------------
 gdbserver/configure.ac    | 23 ++++++-----------------
 gdbsupport/common-defs.h  |  2 +-
 gnulib/import/pathmax.h   |  8 ++++++++
 gnulib/import/rawmemchr.c |  8 +++++++-
 include/libiberty.h       |  8 ++++++++
 8 files changed, 33 insertions(+), 37 deletions(-)

diff --git a/configure b/configure
index 2861694673e..1648f8f60c1 100755
--- a/configure
+++ b/configure
@@ -3203,7 +3203,7 @@ fi
 
 if test "$enable_gprofng" = "yes"; then
   case "${target}" in
-    *-musl*)
+    *-musl* | *-android*)
       ;;
     x86_64-*-linux* | i?86-*-linux* | aarch64-*-linux* | riscv64-*-linux*)
     configdirs="$configdirs gprofng"
diff --git a/configure.ac b/configure.ac
index cae0042411b..4a7a9e4916d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -415,7 +415,7 @@ enable_gprofng=$enableval,
 enable_gprofng=yes)
 if test "$enable_gprofng" = "yes"; then
   case "${target}" in
-    *-musl*)
+    *-musl* | *-android*)
       ;;
     x86_64-*-linux* | i?86-*-linux* | aarch64-*-linux* | riscv64-*-linux*)
     configdirs="$configdirs gprofng"
diff --git a/gdbserver/configure b/gdbserver/configure
index e00e1e1c1c5..acb0eea610c 100755
--- a/gdbserver/configure
+++ b/gdbserver/configure
@@ -13269,20 +13269,7 @@ _ACEOF
 fi
 
 
-case "${target}" in
-  *-android*)
-    # Starting with NDK version 9, <elf.h> actually includes definitions
-    # of Elf32_auxv_t and Elf64_auxv_t. But sadly, <elf.h> includes
-    # <sys/exec_elf.h> which defines some of the ELF types incorrectly,
-    # leading to conflicts with the definitions from <linux/elf.h>.
-    # This makes it impossible for us to include both <elf.h> and
-    # <linux/elf.h>, which means that, in practice, we do not have
-    # access to Elf32_auxv_t and Elf64_auxv_t on this platform.
-    # Therefore, do not try to auto-detect availability, as it would
-    # get it wrong on this platform.
-    ;;
-  *)
-    ac_fn_c_check_type "$LINENO" "Elf32_auxv_t" "ac_cv_type_Elf32_auxv_t" "#include <elf.h>
+ac_fn_c_check_type "$LINENO" "Elf32_auxv_t" "ac_cv_type_Elf32_auxv_t" "#include <elf.h>
 
 "
 if test "x$ac_cv_type_Elf32_auxv_t" = xyes; then :
@@ -13305,8 +13292,6 @@ _ACEOF
 
 fi
 
-esac
-
 
 
 # Check whether --with-pkgversion was given.
diff --git a/gdbserver/configure.ac b/gdbserver/configure.ac
index 16a2520baf4..cc73c22a580 100644
--- a/gdbserver/configure.ac
+++ b/gdbserver/configure.ac
@@ -109,23 +109,12 @@ AC_CHECK_TYPES(socklen_t, [], [],
 #endif
 ])
 
-case "${target}" in
-  *-android*)
-    # Starting with NDK version 9, <elf.h> actually includes definitions
-    # of Elf32_auxv_t and Elf64_auxv_t. But sadly, <elf.h> includes
-    # <sys/exec_elf.h> which defines some of the ELF types incorrectly,
-    # leading to conflicts with the definitions from <linux/elf.h>.
-    # This makes it impossible for us to include both <elf.h> and
-    # <linux/elf.h>, which means that, in practice, we do not have
-    # access to Elf32_auxv_t and Elf64_auxv_t on this platform.
-    # Therefore, do not try to auto-detect availability, as it would
-    # get it wrong on this platform.
-    ;;
-  *)
-    AC_CHECK_TYPES([Elf32_auxv_t, Elf64_auxv_t], [], [],
-    #include <elf.h>
-    )
-esac
+# Modern NDKs expose Elf32_auxv_t/Elf64_auxv_t as typedefs in <elf.h>;
+# auto-detect them instead of assuming Android lacks them (the old NDK 9
+# <sys/exec_elf.h> conflict no longer exists).
+AC_CHECK_TYPES([Elf32_auxv_t, Elf64_auxv_t], [], [],
+#include <elf.h>
+)
 
 ACX_PKGVERSION([GDB])
 ACX_BUGURL([http://www.gnu.org/software/gdb/bugs/])
diff --git a/gdbsupport/common-defs.h b/gdbsupport/common-defs.h
index 1c0ae0ad9d1..b29a81ada40 100644
--- a/gdbsupport/common-defs.h
+++ b/gdbsupport/common-defs.h
@@ -79,7 +79,7 @@
    _FORTIFY_SOURCE there.  */
 
 #if (!defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0 \
-     && !defined(__MINGW32__))
+     && !defined(__MINGW32__) && !defined(__ANDROID__))
 #define _FORTIFY_SOURCE 2
 #endif
 
diff --git a/gnulib/import/pathmax.h b/gnulib/import/pathmax.h
index 19b93d7eab1..6749e699e94 100644
--- a/gnulib/import/pathmax.h
+++ b/gnulib/import/pathmax.h
@@ -47,6 +47,14 @@
 #  define _POSIX_PATH_MAX 256
 # endif
 
+# if defined __ANDROID__ && !defined PATH_MAX
+/* bionic's <sys/param.h> defines MAXPATHLEN as PATH_MAX, but PATH_MAX
+   comes from <linux/limits.h> and may not be exposed by the compiler's
+   <limits.h>.  Include it here so that the MAXPATHLEN fallback below does
+   not define PATH_MAX in terms of itself.  */
+#  include <linux/limits.h>
+# endif
+
 /* Don't include sys/param.h if it already has been.  */
 # if defined HAVE_SYS_PARAM_H && !defined PATH_MAX && !defined MAXPATHLEN
 #  include <sys/param.h>
diff --git a/gnulib/import/rawmemchr.c b/gnulib/import/rawmemchr.c
index ea68c1bfc6a..50d5918ba07 100644
--- a/gnulib/import/rawmemchr.c
+++ b/gnulib/import/rawmemchr.c
@@ -35,7 +35,13 @@ rawmemchr (const void *s, int c_in)
   /* Change this typedef to experiment with performance.  */
   typedef uintptr_t longword;
   /* If you change the "uintptr_t", you should change UINTPTR_WIDTH to match.
-     This verifies that the type does not have padding bits.  */
+     This verifies that the type does not have padding bits.  bionic's
+     <stdint.h> defines UINTPTR_WIDTH in terms of __UINTPTR_WIDTH__, which GCC
+     does not predefine, so derive the width from the type in that case.  */
+#ifndef __UINTPTR_WIDTH__
+# undef UINTPTR_WIDTH
+# define UINTPTR_WIDTH (sizeof (uintptr_t) * CHAR_BIT)
+#endif
   verify (UINTPTR_WIDTH == UCHAR_WIDTH * sizeof (longword));
 
   const unsigned char *char_ptr;
diff --git a/include/libiberty.h b/include/libiberty.h
index bdb491b9b37..6c1f31aa4f7 100644
--- a/include/libiberty.h
+++ b/include/libiberty.h
@@ -48,6 +48,14 @@ extern "C" {
 
 #include <stdio.h>
 
+/* bionic's <sys/param.h> defines MAXPATHLEN in terms of PATH_MAX, but
+   PATH_MAX lives in <linux/limits.h> and is not exposed by every
+   compiler's <limits.h>.  Make it available before any PATH_MAX or
+   MAXPATHLEN use.  */
+#if defined (__ANDROID__) && !defined PATH_MAX
+# include <linux/limits.h>
+#endif
+
 /* If the OS supports it, ensure that the supplied stream is setup to
    avoid any multi-threaded locking.  Otherwise leave the FILE pointer
    unchanged.  If the stream is NULL do nothing.  */
-- 
2.56.0


      reply	other threads:[~2026-10-29 12:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29 12:41 [PATCH 0/1] " trcrsired
2026-10-29 12:41 ` trcrsired [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261029124117.13519-2-oyzawqgcfc@gmail.com \
    --to=oyzawqgcfc@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox