This is a followup to [1] which fixed the x86 build for glibc 2.27. But there
was a similar block of code that was only present on arm, which was causing the
arm build to fail. This CL makes the equivalent change to [1].
[1] 3a20d34ac3
BUG=chromium:843240
R=mark@chromium.org
Change-Id: I4b2786ddcdd0d9920aca25b3ad00c5ba716ca30a
Reviewed-on: https://chromium-review.googlesource.com/1060155
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Glibc now defines PTRACE_GET_THREAD_AREA as an enum value. Trying to define our
own will result in an error:
../../third_party/crashpad/crashpad/compat/linux/sys/ptrace.h:25:35: error: redefinition of 'PTRACE_GET_THREAD_AREA' as different kind of symbol
static constexpr __ptrace_request PTRACE_GET_THREAD_AREA =
^
../../build/linux/debian_sid_amd64-sysroot/usr/include/x86_64-linux-gnu/sys/ptrace.h:110:3: note: previous definition is here
PTRACE_GET_THREAD_AREA = 25,
However, glibc also defines a new macro for the corresponding value, so it's
possible to detect this case:
----- ptrace.h -----
/* Get a TLS entry in the GDT. */
PTRACE_GET_THREAD_AREA = 25,
#define PT_GET_THREAD_AREA PTRACE_GET_THREAD_AREA
----- ptrace.h -----
This CL prevents defining our own PTRACE_GET_THREAD_AREA when PT_GET_THREAD_AREA
is defined.
Bug: None
Change-Id: Idf931e54dadd57788f04da47f12f0f0588a255cc
Reviewed-on: https://chromium-review.googlesource.com/999161
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
user_vfp is not declared anymore in sys/user.h, but in specific
internal kernel asm user.h in GLIBC. So building crashpad on ARMEL
with such a GLIBC will fail to build.
Also, sys/ptrace.h will not include the declarations for
PTRACE_GET_THREAD_AREA and PTRACE_GETVFPREG in arm (they are in
asm/ptrace.h and not included from sys/ptrace.h). So provide
compatibility declarations accordingly for arm architecture.
Change-Id: I58ab5274a66d84c0cbc9e9e9b23e0abc37bf67e5
Reviewed-on: https://chromium-review.googlesource.com/996073
Reviewed-by: Mark Mentovai <mark@chromium.org>
glibc’s own <sys/ptrace.h> should provide this but doesn’t. See
https://sourceware.org/bugzilla/show_bug.cgi?id=22433.
The copy in compat provided it when targeting x86-64 and using glibc.
util/linux/ptracer.cc uses it when targeting both 32-bit x86 and x86-64,
so the compat definition must be made to apply to 32-bit x86 too.
This also provides a #define using the same name as the constant, which
is what glibc’s <sys/ptrace.h> does for other constants.
Bug: crashpad:30
Change-Id: I5a0734a236d1c25398fb69e66f58dfe118658b68
Reviewed-on: https://chromium-review.googlesource.com/765257
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Linux supports TLS on x86 by allocating slots in the GDT, accessible
via the system calls get/set_thread_area. This allows segment
registers (%gs on x86) to be used to quickly access the TLS.
Previously, we used PTRACE_GETREGSET with the NT_386_TLS regset. This
"register set" provides access to the subarray of the GDT used for TLS.
However, there are multiple slots provided and we don't know which one
is being used by the threading library for the current thread's TLS.
Previously, we were just using the first one, which worked for x86 on
64-bit kernels, but not 32-bit kernels. On 32-bit kernels, the first
slot ended up pointing to the TLS of the main thread.
The authoritative index of the current thread's TLS in the GDT is
given by bits 3-15 of %gs. However, this index cannot be used with
PTRACE_GETREGSET+NT386_TLS because we don't know the location of the
TLS slots in the GDT. PTRACE_GET_THREAD_AREA, however, accepts an
index from the start of the GDT similarly to get/set_thread_area.
Bug: crashpad:30
Change-Id: Ie6dfbdd088c6816fad409812a1a97037d4b38fd7
Reviewed-on: https://chromium-review.googlesource.com/575318
Reviewed-by: Mark Mentovai <mark@chromium.org>
