Because of the multiple-worlds building of the Crashpad code in the
Fuchsia tree (with the Fuchsia BUILDCONFIG.gn in particular) there's no
good location to globally disable Wconversion for all of crashpad.
This can be somewhat-improved by using a GN template
crashpad_static_library() similar to the existing crashpad_executable()
template.
Includes mini_chromium DEPS roll:
68da43e Fix a couple trucation warnings
88ce866 build: set include dirs
Bug: fuchsia:58162
Change-Id: I638fcf858c35b9a858ca2c410636f8c99603aed2
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2411131
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
CFI attempts to verify that the dynamic type of a function object
matches the static type of the function pointer used to call it.
https://clang.llvm.org/docs/ControlFlowIntegrity.html#indirect-function-call-checking
However, the analyzer does not have enough information to check
cross-dso calls. In these instances, CFI crashes upon calling the
function with an error like:
pthread_create_linux.cc:60:16: runtime error:
control flow integrity check for type
'int (unsigned long *, const pthread_attr_t *, void *(*)(void *), void *)'
failed during indirect function call
(/lib/x86_64-linux-gnu/libpthread.so.0+0x9200):
note: (unknown) defined here pthread_create_linux.cc:60:16:
note: check failed in crashpad_handler,
destination function located in /lib/x86_64-linux-gnu/libpthread.so.0
Change-Id: Ib29dabfe714f2ee9cc06a5d17e6899ff81a06df4
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2339332
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The macOS 11.0 SDK, as of Xcode 12b6 12A8189n, has not updated
<AvailabilityMacros.h> with a MAC_OS_X_VERSION_11_0 or
MAC_OS_X_VERSION_10_16 constant. However, the <Availability.h> interface
has been updated to provide both __MAC_11_0 and __MAC_10_16.
<AvailabilityMacros.h>’s MAC_OS_X_VERSION_MAX_ALLOWED, which is supposed
to identify the SDK version, is broken in the 11.0 SDK in that whenever
the deployment target is set to 10.15 or earlier, the SDK will be
mis-identified through this interface as 10.15. When using the
<Availability.h> equivalent, __MAC_OS_X_VERSION_MAX_ALLOWED, the 11.0
SDK is identified as 10.16 (arguably it should be internally versioned
as 11.0, but at least this interface allows it to be detected
unambiguously.) It’s clear that the <AvailabilityMacros.h> interface
provides no meaningful support for the macOS 11.0 SDK at all, but
<Availability.h> does.
<Availability.h> was introduced in the Mac OS X 10.5 SDK, so there is no
relevant SDK version compatibility problem with this interface.
Key differences between these interfaces for the purposes used by
Crashpad:
- <AvailabilityMacros.h> → <Availability.h>
- MAC_OS_X_VERSION_MIN_REQUIRED (DT) → __MAC_OS_X_VERSION_MIN_REQUIRED
- MAC_OS_X_VERSION_MAX_ALLOWED (SDK) → __MAC_OS_X_VERSION_MAX_ALLOWED
- MAC_OS_X_VERSION_x_y → __MAC_x_y
- <Availability.h> __MAC_OS_X_VERSION_* SDK/DT macros are only
available when targeting macOS, while <AvailabilityMacros.h>
MAC_OS_X_VERSION_* SDK/DT macros are available on all Apple platforms,
which may be a source of confusion. (<Availability.h> __MAC_* macros
do remain available on all Apple platforms.)
This change was made mostly mechanically by:
sed -i '' -Ee 's/<AvailabilityMacros.h>/<Availability.h>/g' \
$(git grep -E -l '<AvailabilityMacros.h>' |
grep -v AvailabilityMacros.h)
sed -i '' -Ee 's/(MAC_OS_X_VERSION_(MIN_REQUIRED|MAX_ALLOWED))/__\1/g' \
$(git grep -E -l 'MAC_OS_X_VERSION_(MIN_REQUIRED|MAX_ALLOWED)' |
grep -v AvailabilityMacros.h)
sed -i '' -Ee 's/(MAC_OS_X_VERSION_(10_[0-9]+))/__MAC_\2/g' \
$(git grep -E -l 'MAC_OS_X_VERSION_(10_[0-9]+)' |
grep -v AvailabilityMacros.h)
Bug: crashpad:347
Change-Id: Ibdcd7a6215a82f7060b7b67d98691f88454085fc
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2382421
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
On Android, the compat library built compat/android/sys/mman.cc, which
provides a fallback for mmap, and compat/linux/sys/mman.cc, which
provides a fallback for memfd_create. This can result in two object
files colliding in the library, which is flagged as a “gn analyze”
error:
> ERROR at //crashpad/compat/BUILD.gn:62:5: Duplicate object file
> static_library(target_name) {
> ^----------------------------
> The target //crashpad/compat:compat
> generates two object files with the same name:
> obj/crashpad/compat/compat/mman.o
>
> It could be you accidentally have a file listed twice in the
> sources. Or, depending on how your toolchain maps sources to
> object files, two source files with the same name in different
> directories could map to the same object file.
>
> In the latter case, either rename one of the files or move one of
> the sources to a separate source_set to avoid them both being in
> the same target.
The files are renamed to avoid this collision. The associated headers
cannot be renamed because they need to shadow the SDK’s copies. There is
no “gn analyze” conflict reported for headers with the same name.
Change-Id: Ia49ef5ff8375673395597e96555f72f7c69e3564
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2285965
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Chromium relies on a global gn sources assignment filter, even though
it’s kind of discouraged. Crashpad doesn’t use this, instead selecting
which files to build entirely with the logic in its .gn files. In some
cases, Chromium’s filters prevent _linux files from building on Android,
and _mac files from building on iOS, even though Crashpad’s build has
explicitly requested these inclusions. To overcome this problem,
clear the gn sources_assignment_filter in all of Crashpad’s own .gn
files when building in Chromium.
Change-Id: Iab0af29f4e5aff4be8eec2ee12b2e3f991c0a86d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2285959
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
This updates the way that the .defs files added in 1bfd7d06ed60 are
treated, by putting them in compat/ios, using compat as intended. The
.defs files in compat forward, via #include, to the ones in
third_party/xnu. Additionally, compat/mac is enabled for iOS, as
everything in compat/mac is sensible on iOS, and will have no effect
when rendered unnecessary by the iOS SDK.
This also changes util:mig_output to a static_library instead of a
source_set. I don’t think there was any reason for it to have been a
source_set to begin with. static_library is preferred for nearly
everything.
Bug: crashpad:31
Change-Id: I7c468d6d6785bf2bc825d45831ebb81e1c9ddfbc
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2160310
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
First steps at bringing up the crashpad_client on iOS. Also updates
the XCUITest to trigger various crashes, with some swizzling
necessary to allow crashes.
Change-Id: I87dd36bed1c052b509d14bfa29679ed81e58a377
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2039470
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
macOS 10.15 (“Catalina”) introduces a single new field to its
dyld_all_image_infos structure, and uses structure version 16.
macOS 10.13 and 10.14 were documented in <mach-o/dyld_images.h> as using
structure version 16, but they actually use version 15. They should have
used version 16, as they do use a structure expanded from macOS 10.12,
which also uses version 15. Previously, process_types was true to the
documentation, but now that this is known to be incorrect, it’s been
revised to reflect reality. Because two variants of the version 15
structure exist, run-time OS version detection is used to disambiguate.
Bug: crashpad:310
Test: crashpad_snapshot_test ProcessTypes.DyldImagesSelf (10.15 SDK)
Change-Id: Ibc82b6a73809949f4bbf416ece7aa955b627c573
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1852109
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
NDK r20 provides a declaration of android_get_device_api_level() at API level
29, and an inline definition at older API levels. The latter conflicts with
crashpad's definition, so stop defining it if the NDK is new enough.
Bug: chromium:891999
Change-Id: If58542c9d6b5315f823f2509f168f2cb79141e3f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1739512
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
I’m working on something that I’m not ready to share, but maintaining
these compat headers in my local branch is becoming annoying because
“git cl format” keeps reformatting them since they were added since my
local branch point.
Because these headers are non-trivial, they’re brought nearly unmodified
from upstream into third_party, with forwarding from the appropriate
locations in compat.
<elf.h> comes from glibc 2.29 (2019-01-31) and was modified to remove
the #include of <features.h> and to replace the use of __BEGIN_DECLS and
__END_DECLS with the proper conditional extern "C" construct.
<mach-o/loader.h> comes from xnu 4903.221.2 (macOS 10.14.1, 2018-10-30)
and was modified to remove the unused #includes of
<mach/machine/thread_status.h> and <architecture/byte_order.h>. Rather
than taking <mach/machine.h> and <mach/vm_prot.h> with a spider web of
other dependencies from xnu, compat has cut-back versions of these
headers that provide only the required typedefs.
This also includes an update of apple_cf to 1153.18 (OS X 10.10.3,
2015-04-08), the last public release of CF-Lite. The change doesn’t do
much for our purposes, but it restores the file to an Apple-shipped
state, trailing whitespace and all.
This also canonically formats BUILD.gn. 48ee086ca4c4c didn’t format it.
Change-Id: Ib4f28ad53d9757bd0eed838e148c51172bfe30b1
Reviewed-on: https://chromium-review.googlesource.com/c/1489795
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
A uint8_t won't be bit-extended, zero-ing all the upper bits of value.
Change-Id: Iae41eeb4a014de5ed47ad599081959250a7bbe9c
Reviewed-on: https://chromium-review.googlesource.com/c/1405691
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Add MemoryMap::Iterator to support different strategies for locating
the start of module mappings on Android and Linux.
Beginning with API 21, Bionic provides android_dlopen_ext() which
allows passing a file descriptor with an existing relro segment to the
loader. This means that the mapping containing the dynamic segment
could have a name, device, and inode which are different than the
other mappings for the module.
The revised strategy for Android at API 21+ is to search all mappings
in reverse order from they dynamic array mapping until a module is
parsed with the expected dynamic array address.
Linux and Android 20- continue to select mappings using the device,
inode, and file offsets of the mappings.
Bug: crashpad:268
Change-Id: I30e95e51cb6874c00875d2a9c57f1249877736d4
Reviewed-on: https://chromium-review.googlesource.com/c/1374375
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
PTRACE_GET_THREAD_AREA is only removed from the newer version of glibc (>=2.28)
for aarch64. Since ChromeOS uses 2.23 version of glibc currently,
so it should be handled in crashpad to avoid the redefinition.
BUG=chromium:873168
Change-Id: I8da6bc0595b814b0490b38da6f4a68e6803bb5b9
Reviewed-on: https://chromium-review.googlesource.com/1188309
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
__aarch64__ should always be defined for 64-bit ARM, while __arm64__
only sometimes is.
Change-Id: I46a6469d8f5e74ad79b6ded51a809fbf88e5170a
Reviewed-on: https://chromium-review.googlesource.com/1151541
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
The pre-processor attempts to parse an entire expression before
evaluating sub-expressions, so undefined macros result in a syntax
error.
Change-Id: Ie950867897a1befd221bdbe4719f2365f5cc75ee
Reviewed-on: https://chromium-review.googlesource.com/1132328
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
On Linux and macOS, compat.gyp:crashpad_compat is a header-only target,
which should be declared type=none.
This CL also adds the missing non_mac/ include_dirs for non-macOS
targets.
Bug: crashpad:
Change-Id: I7bef32e8f6bdcb86f51118a1bb1d3b52d05120d1
Reviewed-on: https://chromium-review.googlesource.com/1124773
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
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>
`dlsym` on Android KitKat (4.4.*) raises SIGFPE when searching for
non-existent symbols. This wrapper installs a signal handler prior to
calling `dlsym`.
Bug: crashpad:30
Change-Id: Iee94672d3c11b1fad1b01526eea7df688c0356cb
Reviewed-on: https://chromium-review.googlesource.com/835411
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
With a companion mini_chromium change at https://crrev.com/c/841203,
it’s possible to configure via “gn args” as follows:
android_ndk = "/android/android-ndk-r16"
target_cpu = "x86_64"
target_os = "android"
Note that a standalone toolchain is not required.
Bug: crashpad:30, crashpad:79
Change-Id: Ica55bdcb82c730909c05dd9fecb40a74eca78c8a
Reviewed-on: https://chromium-review.googlesource.com/841286
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This is sufficient for a native Linux build using GN. Android is not yet
supported.
mini_chromium side: https://crrev.com/c/833407
This also updates mini_chromium to 404f6dbf9928.
c913ef97a236 gn, linux: Build for Linux with GN
404f6dbf9928 gn: Don’t use .rsp files; rationalize descriptions and
output dirs
Bug: crashpad:79
Change-Id: I4f3b72fd02884d77812e520fb95231b35815677d
Reviewed-on: https://chromium-review.googlesource.com/833408
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
These are present on 10.7 and later, and were only provided for the
benefit of older systems that probably aren’t relevant to Crashpad any
longer.
Change-Id: If9d7222f7af05020d0ff57d5d9ed06355fa14a48
Reviewed-on: https://chromium-review.googlesource.com/827686
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Although API 21 introduced support for 64-bit off_t in many system calls
or their wrappers, <stdio.h> support for 64-bit off_t is absent until
API 24.
This is a partial revert of 5969d6b1eb22, because with this more
targeted fix applying only to gtest, the rest of Crashpad will work with
a 64-bit off_t even at API levels lacking NDK support by going through
the mmap() shim in compat.
This includes a mini_chromium update to 96e32dd499a4.
85cbec19ffc0 fuchsia: Make EINTR macros no-ops
fbf410cd4d40 fuchsia: Use koid instead of getpid() for process field in
logging
96e32dd499a4 Revert "android: Don’t use _FILE_OFFSET_BITS=64 until API
21"
Bug: crashpad:211
Change-Id: I34c3c8b42eb315605e6775962b44c3c4573b7462
Reviewed-on: https://chromium-review.googlesource.com/811204
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This updates build/gyp_crashpad_android.py to define the
android_api_level GYP variable whenver unified headers are in use.
Previously, it was only set when compiling with GCC and using unified
headers. This pairs with https://crrev.com/c/804574 to allow proper
detection of when _FILE_OFFSET_BITS=64 would be inappropriate.
Since there’s no longer any possibility of using a 64-bit off_t with API
< 21, this also drops the compatibility wrapper for mmap() that allowed
this configuration to work. Too bad, I liked this, but it’s pointless to
carry now.
The development documentation is also updated to refer to NDK r16.
mini_chromium is updated to 88e056258a01450b07414642fa5fb98493c1f6ce.
f609089390cd fuchsia: Add ZX_LOG, et al. to mini_chromium
0a8c5de30c67 fuchsia: Fix RandBytes() ZX_CHECK message string
88e056258a01 android: Don’t use _FILE_OFFSET_BITS=64 until API 21
Change-Id: I932116e0c01bcddd5719f9091a070d504eae600f
Reviewed-on: https://chromium-review.googlesource.com/804555
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
When I redid the Crashpad GN build a few weeks ago
(https://chromium-review.googlesource.com/c/chromium/src/+/751403), I
tried to order things according to the GN style guide
(https://chromium.googlesource.com/chromium/src/tools/gn/+/HEAD/docs/style_guide.md).
As for conditionals, I tried to stick to doing a set of conditionals
after “sources” for just “sources”, and then another one at the bottom
for everything else.
It turns out that this was a good idea because it’s an error to say
“deps += [something]” inside a conditional until you’ve already said
“deps = [something_else]” first. (Maybe that’s why I did it.)
9465fc72ad90 regressed this.
2bb56fafe3bd also left behind a couple of straggler paths that were
absolute to Chromium’s root but should have been made relative.
This also fixes a comment (about something that won’t yet work outside
of Chromium anyway, but still…)
Bug: crashpad:79
Change-Id: I8a6f84bfad368cbcdae4fbff11f1d00e2af14b93
Reviewed-on: https://chromium-review.googlesource.com/798172
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
- Adds a .gn and a build/BUILDCONFIG.gn that uses mini_chromium's
build/BUILD.gn.
- Adds some stub BUILD.gn files in locations where Chromium expects them
(in //build, //testing, //third_party) containing empty targets/configs.
These are no-ops in standalone builds, but add functionality when
building in Chromium. This is in preference to having a global bool
that conditionally does Chromium-y things in the Crashpad build files.
These stub files are all contained in a secondary source root in
build/chromium_compatibility, referred to by //.gn.
- Adds //base/BUILD.gn which forwards to mini_chromium/base. This is
only used when building standalone so that both Chromium and Crashpad
can refer to it as "//base".
- Changes references to other Crashpad targets to be relatively
specified so that they work when the root of the project is //, and also
when it's //third_party/crashpad/crashpad as it is in Chromium.
- Moves any error-causing Mac/Win-specific files into explicit if (is_mac)
or if (is_win) blocks as part of removing the dependency on
set_sources_assignment_filter().
As yet unresolved:
- CRASHPAD_IN_CHROMIUM needs to be removed when standalone; to be tackled
in a follow up.
- Not sure what to do with zlib yet, the build file currently assumes
"in Chromium" too, and similarly having Crashpad //third_party/zlib:zlib
pointing at itself doesn't work.
Bug: crashpad:79
Change-Id: I6a7dda214e4b3b14a60c1ed285267ab97432a1a8
Reviewed-on: https://chromium-review.googlesource.com/777410
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Change-Id: I4b247d7fae1a212350f8ffcf2bf5ba1fa730f5c1
Reviewed-on: https://chromium-review.googlesource.com/780339
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Unreferenced, and not working at all in Crashpad-standalone.
Copied from Chromium at 52a9831d81f2099ef9f50fcdaca5853019262c35 to have
a point where a roll back into Chromium should be a no-op (with Chromium's
build/secondary/third_party/crashpad/... removed).
I'm not sure what we want to do about the various gni references into
Chromium (e.g. //build/config/sanitizers/sanitizers.gni, //testing/test.gni,
etc.) but I guess the sooner they live in Crashpad rather than in Chromium
the sooner we can figure out the sort of knobs and dials we need.
Bug: crashpad:79
Change-Id: Id99c29123bcd4174ee2bcc128c2be87e3c94fa3f
Reviewed-on: https://chromium-review.googlesource.com/777819
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@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>
As mentioned at
https://chromium-review.googlesource.com/c/chromium/src/+/735820#message-e8b199498d8b850f2612c46648069d819dd47517,
the typical Windows behavior for symbolic links requires administrative
privileges.
Symbolic links are available to non-administrators in Windows 10.0.15063
and later (1703, Creators Update), provided that developer mode has been
enabled and SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE is passed to
CreateSymbolicLink(). See
https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/.
This adds SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE to uses of
CreateSymbolicLink(), and creates test::CanCreateSymbolicLinks() to
determine whether symbolic link creation is possible. Tests that
exercise symbolic links are adapted to gate all symbolic link operations
on this test.
Test: crashpad_util_test DirectoryReader.*:Filesystem.*
Change-Id: I8250cadd974ffcc7abe32701a0d5bc487061baf0
Bug: crashpad:
Reviewed-on: https://chromium-review.googlesource.com/739472
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
This corresponds to Windows 10 version 1709 (Fall Creators Update,
“Redstone 3”).
While compiling util/win/nt_internals.cc:
…\crashpad\crashpad\util\win\nt_internals.cc(22): error C2371: 'CLIENT_ID': redefinition; different basic types
c:\program files (x86)\windows kits\10\include\10.0.16299.0\um\winternl.h(83): note: see declaration of 'CLIENT_ID'
The CLIENT_ID structure, which should have been part of the SDK to begin
with, has been added. Provide a compatible definition in <winternl.h>.
Bug: chromium:773476
Change-Id: Iafc77f8cffd06d1194fc909bad587f1ffd1687a2
Reviewed-on: https://chromium-review.googlesource.com/711415
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
