From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
To: gdb-patches ml <gdb-patches@sourceware.org>
Subject: [RFA] Define Elf32_auxv_t and Elf64_auxv_t if not available.
Date: Mon, 26 Mar 2012 18:49:00 -0000 [thread overview]
Message-ID: <1332787763.30339.10.camel@hactar> (raw)
Hi,
glibc's <elf.h> says this about Elf32_auxv_t and Elf64_auxv_t:
The vector is not usually defined in a standard <elf.h> file, but it
can't hurt. We rename it to avoid conflicts.
Android's bionic libc doesn't define these types in <elf.h>. To be
honest I couldn't find a definition for auxv_t in ARM's EABI and I'm not
aware of an Android EABI document. I confirmed that bionic internally
uses this format though, and this definition seems unlikely to change.
Ok to commit? It doesn't affect compilation in i386-linux or
armv5tel-linux-gnueabi.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
2012-03-26 Thiago Jung Bauermann <thiago.bauermann@linaro.org>
* configure.ac: Check whether Elf32_auxv_t and Elf64_auxv_t
are available.
* linux-low.c [HAVE_ELF32_AUXV_T] (Elf32_auxv_t): Add typedef.
[HAVE_ELF64_AUXV_T] (Elf64_auxv_t): Likewise.
diff --git a/gdb/gdbserver/configure.ac b/gdb/gdbserver/configure.ac
index e6e9162..6b98dc0 100644
--- a/gdb/gdbserver/configure.ac
+++ b/gdb/gdbserver/configure.ac
@@ -163,9 +163,10 @@ fi
AC_CHECK_DECLS([strerror, perror, memmem, vasprintf, vsnprintf])
-AC_CHECK_TYPES(socklen_t, [], [],
+AC_CHECK_TYPES([socklen_t, Elf32_auxv_t, Elf64_auxv_t], [], [],
[#include <sys/types.h>
#include <sys/socket.h>
+#include <elf.h>
])
ACX_PKGVERSION([GDB])
diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c
index d2d4c1d..9aef4db 100644
--- a/gdb/gdbserver/linux-low.c
+++ b/gdb/gdbserver/linux-low.c
@@ -82,6 +82,34 @@
#endif
#endif
+#ifndef HAVE_ELF32_AUXV_T
+typedef struct
+{
+ uint32_t a_type; /* Entry type */
+ union
+ {
+ uint32_t a_val; /* Integer value */
+ /* We use to have pointer elements added here. We cannot do that,
+ though, since it does not work when using 32-bit definitions
+ on 64-bit platforms and vice versa. */
+ } a_un;
+} Elf32_auxv_t;
+#endif
+
+#ifndef HAVE_ELF64_AUXV_T
+typedef struct
+{
+ uint64_t a_type; /* Entry type */
+ union
+ {
+ uint64_t a_val; /* Integer value */
+ /* We use to have pointer elements added here. We cannot do that,
+ though, since it does not work when using 32-bit definitions
+ on 64-bit platforms and vice versa. */
+ } a_un;
+} Elf64_auxv_t;
+#endif
+
/* ``all_threads'' is keyed by the LWP ID, which we use as the GDB protocol
representation of the thread ID.
next reply other threads:[~2012-03-26 18:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-26 18:49 Thiago Jung Bauermann [this message]
2012-03-27 15:21 ` Joel Brobecker
2012-03-28 0:12 ` Thiago Jung Bauermann
2012-03-29 16:03 ` Pedro Alves
2012-03-30 20:26 ` Thiago Jung Bauermann
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=1332787763.30339.10.camel@hactar \
--to=thiago.bauermann@linaro.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