This CL adds the Shipped field in READMEs. See the LSC
doc at go/lsc-chrome-metadata.
Bug: b:285450740
Change-Id: I3dcd5e027f06982f4c2dd98136d3a6d7f6228b4e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4666416
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
mig was being invoked without any -arch argument, causing it to assume
the build system’s native architecture, which would be x86_64. This is
not correct for iOS device builds, which use arm64. The -arch argument
must be plumbed to mig for correct behavior.
When building for iOS, mig was being invoked without any -isysroot
argument, causing it to use the root for the build system, which runs
macOS and not iOS. The macOS SDK doesn’t include the ARM definitions
needed for iOS device builds.
<mach/exc.defs> and <mach/mach_exc.defs> depend on a small number of
other .defs files to provide definitions of standard types. All .defs
files are absent from the iOS SDK. These .defs files are borrowed from
xnu and placed in third_party/xnu. An additional --include argument is
added to allow mig to locate these files.
Bug: crashpad:31
Change-Id: I27154310352939ebe2fb6329bbbfda701c369289
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2159291
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This updates (and corrects) 8dbbaff2e1a5, which added exc.defs, by
adding mach_exc.defs too.
The difference betwen the exc and mach_exc subsystems is that the |code|
parameter is int[] in exc and int64_t[] in mach_exc. Many exceptions
carry the exception address in code[1], and a 32-bit int results in the
exception address being truncated in exc. No information is lost in
mach_exc, where a 64-bit int64_t is used.
In 8dbbaff2e1a5, I misremembered the type of the |code| parameter as a
type derived from uintptr_t, such as vm_address_t, an integer as wide as
a pointer. I was wrong, and mach_exc is necessary. I also noted that
Apple normally forbids mach_-prefixed interfaces in favor of the
prefix-less ones for the reasons I mentioned, and that, all else being
equal, it was desirable to adhere to the spirit of that convention.
Because neither exc nor mach_exc are available in the SDK, it’s moot
from a technical perspective, as we need to provide our own stubs either
way.
Bug: crashpad:31
Change-Id: Ied1be470e653b2bead1a283cb8b9283d210c328d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2159286
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
The iOS SDK doesn’t include a copy of <mach/exc.defs>. It only provides
<mach/exc.h>, which is just the user-side header. To obtain declarations
and implementations of the server-side stubs, a current copy of
<mach/exc.defs> is added to third_party, and the mig action in util is
updated to use it on iOS.
The three other mig subsystems that Crashpad uses are not brought to
iOS:
- mach_exc is identical to exc except it always uses 64-bit quantities
for addresses in place of exc’s use of quantiies sized for native
pointers. Because all iOS work is limited to a single process, there
is no need to consider cross-process operation with variable bitness,
so mach_exc is unnecessary. We’re also only targeting 64-bit for iOS,
so exc will always suffice. This follows the spirit of other
mach_-prefixed routines on iOS, where Apple forbids mach_vm_read to
user applications but permits vm_read.
- notify is primarily used on macOS in the Crashpad handler process to
receive a no-senders notification, which is used to trigger handler
shutdown when it has no more clients. This is not believed to be
useful to Crashpad on iOS, which is restricted to single-process
operation.
- child_port is a Crashpad-specific subsystem used to pass Mach rights
between processes, but is similarly useless when restricted to
single-process operation as on iOS.
Bug: crashpad:31
Change-Id: Id4cb3cdd529814438d378c20702c82c1e89dd2be
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2154530
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Justin Cohen <justincohen@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>
