Debug registers are currently initialized to 0 until methods are added
to ThreadInfo to collect them.
Bug: crashpad:30
Change-Id: Ic1aab1151dcd4bed48eca8a60b76fb0d8d613418
Reviewed-on: https://chromium-review.googlesource.com/579889
Reviewed-by: Mark Mentovai <mark@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>
Dynamic linkers use `struct r_debug` and `struct link_map` (defined in
`<link.h>`) to communicate lists of loaded modules to debuggers.
Bug: crashpad:30
Change-Id: Id903a1c199288dd85c34e38710cdb4c6b5fedb5b
Reviewed-on: https://chromium-review.googlesource.com/534853
Reviewed-by: Mark Mentovai <mark@chromium.org>
ELF executables and libraries may be loaded into memory in several
mappings, possibly with holes containing anonymous mappings
or mappings of other files. This method takes an input mapping and
attempts to find the mapping for file offset 0 of the same file.
Bug: crashpad:30
Change-Id: I79abf060b015d58ef0eba54a399a74315d7d2d77
Reviewed-on: https://chromium-review.googlesource.com/565223
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
user_fxsr_struct is only used in traditional NDK headers. Unified
headers always use user_fpxregs_struct regardless of API level.
Bug: crashpad:30, b/63025548
Change-Id: Id9d350801e659673b136e6fb8c0cbbbeb6055c4b
Reviewed-on: https://chromium-review.googlesource.com/549376
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This renames and improves the VariableSizeBitCast helper from
util/linux/auxiliary_vector.* and moves it to misc.
Change-Id: I4bf46f4cfc0e60c900ff9bde467a21ad43c684cd
Reviewed-on: https://chromium-review.googlesource.com/534174
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
ThreadInfo provides a uniform interface to collect register sets or
the thread-local storage address across bitness for x86 and ARM family
architectures. Additionally, ThreadInfo.h defines context structs which
mirror those provided in sys/user.h. This allows tracing across bitness
as the structs in sys/user.h are only provided for a single target
architecture.
Bug: crashpad:30
Change-Id: I91d0d788927bdac5fb630a6ad3c6ea6d3645ef8a
Reviewed-on: https://chromium-review.googlesource.com/494075
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The lots-of-regions tests in the MemoryMap test case were very
time-consuming, particularly in debug mode. MemoryMap.MapRunningChild
took as long as 15 seconds on-device (Nexus 5X), and the best result was
in the neighborhood of 7 seconds.
The bulk of the time spent in these tests was in ExpectMappings(), which
calls MemoryMap::FindMapping() in a loop to verify each region. Each
call to FindMapping() traverses the MemoryMap (internally, currently
just a std::vector<>) from the beginning. With the need to verify 4,096
regions, a single call to ExpectMappings() had to perform over 8,000,000
checks to find the regions it needed. In turn, ExpectMappings() is
called once by the SelfLargeMapFile test, and eight times by
MapRunningChild. By reducing the number of regions to 1,024, each call
to ExpectMappings() needs to perform “only” fewer than 600,000 checks.
After this change, MemoryMap.MapRunningChild completes in about a half a
second on-device.
https://crashpad.chromium.org/bug/181 is concerned with implementing a
RangeMap to serve MemoryMap and other similar code. After that’s done,
it, it should be feasible to raise the number of regions used for these
tests again.
Bug: crashpad:30, crashpad:181
Test: crashpad_util_test MemoryMap.SelfLargeMapFile:MemoryMap.MapRunningChild
Change-Id: I8ff88dac72a63c97ac937304b578fbe3b4ebf316
Reviewed-on: https://chromium-review.googlesource.com/494128
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
When the /proc/pid/maps file is not read atomically and the target
process is actively mapping memory, entries can be read multiple times
or missed entirely. This change makes MemoryMap read the whole contents
of the maps file before attempting to parse it as well as check for
duplication/overlap errors, retrying on failure. This change also adds
ptrace attachements to unit tests to reflect actual intended usage.
Bug: crashpad:30
Change-Id: Ie8549548e25c47baa418ee7439d82743f84ff41e
Reviewed-on: https://chromium-review.googlesource.com/491950
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Some of the new Linux/Android tests were failing in 32-bit code where
pointers were being casted via reinterpret_cast<>() to LinuxVMAddress,
an unsigned 64-bit type. The behavior of such casts is
implementation-defined, and in this case, sign-extension was being used
to convert the 32-bit pointers to 64 bits, resulting in very large
(unsigned) LinuxVMAddress values that could not possibly refer to proper
addresses in a 32-bit process’ address space.
The offending reinterpret_cast<>() conversions have been replaced with
the new FromPointerCast<>(), which is careful to do sign-extension when
converting to a signed type, and zero-extension when converting to an
unsigned type like LinuxVMAddress.
Bug: crashpad:30
Test: crashpad_util_test FromPointerCast*:MemoryMap.*:ProcessMemory.*
Change-Id: I6f1408dc63369a8740ecd6015d657e4407a7c271
Reviewed-on: https://chromium-review.googlesource.com/488264
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This fixes ProcessMemory for 32-bit processes. All ProcessMemory tests
were failing on 32-bit ARM on Android like this:
[ RUN ] ProcessMemory.ReadSelf
[17345:17345:20170407,172222.579687:ERROR process_memory.cc:55] pread: Invalid argument (22)
../../../../util/linux/process_memory_test.cc:73: Failure
Value of: memory.Read(address, region_size_, result.get())
Actual: false
Expected: true
[ FAILED ] ProcessMemory.ReadSelf (5 ms)
Contemporary Linux doesn’t provide a pread() system call, it provides
pread64(), which operates on off64_t. pread() is a user-space wrapper
that accepts off_t. See Android 7.1.1
bionic/libc/bionic/legacy_32_bit_support.cpp pread().
Note that off_t is a signed type. With a 32-bit off_t, when the
“offset” parameter to pread() has its high bit set, it will be
sign-extended into the 64-bit off64_t, and when interpreted as a memory
address by virtue of being used as an offset into /proc/pid/mem, the
value will take on an incorrect meaning. In fact, the kernel will reject
it outright for its negativity. See linux-4.9.20/fs/read_write.c
[sys_]pread64().
Since ProcessMemory accepts its address parameter as a LinuxVMAddress,
which is wisely a uint64_t, it converts to off64_t properly, retaining
its original value.
Note, however, that the pread64() mechanism evidently cannot read memory
in the high half of a process’ address space even when pread64() is used
throughout. Most importantly, the (pos < 0) check in the kernel will be
tripped. Less importantly, the conversion of our unsigned LinuxVMAddress
to pread64’s signed off64_t, with the high bit set, is not defined. This
is not an immediate practical problem. With the exception of possible
shared pages mapped from kernel space (I only see this for the vsyscall
page on x86_64), Linux restricts 64-bit user process’ address space to
at least the lower half of the addressable range, with the high bit
clear. (The limit of the user address space is
linux-4.9.20/arch/x86/include/asm/processor.h TASK_SIZE_MAX =
0x7ffffffff000 for x86_64 and
linux-4.9.20/arch/arm64/include/asm/memory.h TASK_SIZE_64 =
0x1000000000000 at maximum for arm64.)
The 32-bit off_t may be a surprise, because
third_party/mini_chromium/mini_chromium/build/common.gypi sets
_FILE_OFFSET_BITS=64. Altough this macro is considered in the NDK’s
“unified headers”, in the classic NDK, this macro is never consulted.
Instead, off_t is always “long”, and pread() always gets the
compatibility shim in Bionic.
Bug: crashpad:30
Change-Id: Id00c882a3d521a46ef3fc0060d03ea0ab9493175
Reviewed-on: https://chromium-review.googlesource.com/472048
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
When Yama is enabled and /proc/sys/kernel/yama/ptrace_scope is set to 1
(YAMA_SCOPE_RELATIONAL), for a child to ptrace() its parent, the parent
must first call prctl(PR_SET_PTRACER, child_pid, ...).
Bug: crashpad:30
Test: crashpad_util_test ScopedPtraceAttach.*
Change-Id: Ic85e8551259f17f372b2362887e7701b833b4cb4
Reviewed-on: https://chromium-review.googlesource.com/472006
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
gtest used to require (expected, actual) ordering for arguments to
EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify
each side as “expected” or “actual.” Tests in Crashpad adhered to this
traditional ordering. After a gtest change in February 2016, it is now
agnostic with respect to the order of these arguments.
This change mechanically updates all uses of these macros to (actual,
expected) by reversing them. This provides consistency with our use of
the logging CHECK_EQ and DCHECK_EQ macros, and makes for better
readability by ordinary native speakers. The rough (but working!)
conversion tool is
https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py,
and “git cl format” cleaned up its output.
EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made
a judgment that one side or the other needed to provide an “unexpected”
value. Consequently, some code used (unexpected, actual) while other
code used (actual, unexpected). For consistency with the new EXPECT_EQ
and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE,
this change also updates these use sites to (actual, unexpected) where
one side can be called “unexpected” as, for example, std::string::npos
can be. Unfortunately, this portion was a manual conversion.
References:
https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison77d6b17338https://github.com/google/googletest/pull/713
Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3
Reviewed-on: https://chromium-review.googlesource.com/466727
Reviewed-by: Scott Graham <scottmg@chromium.org>
Provides Read, ReadCString, and ReadCStringSizeLimited. Does not provide
ReadMapped because Linux does not support mmap on /proc/pid/mem.
Bug: crashpad:30
Change-Id: Ia319c0107b1f138aeb8e5d0ee480c77310df7202
Reviewed-on: https://chromium-review.googlesource.com/459700
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>