4 Commits

Author SHA1 Message Date
Mark Mentovai
6278690abe Update copyright boilerplate, 2022 edition (Crashpad)
sed -i '' -E -e 's/Copyright (.+) The Crashpad Authors\. All rights reserved\.$/Copyright \1 The Crashpad Authors/' $(git grep -El 'Copyright (.+) The Crashpad Authors\. All rights reserved\.$')

Bug: chromium:1098010
Change-Id: I8d6138469ddbe3d281a5d83f64cf918ec2491611
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3878262
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
2022-09-06 23:54:07 +00:00
Mark Mentovai
50ed179e9a Use BUILDFLAG for OS checking
Use BUILDFLAG(IS_*) instead of defined(OS_*).

This was generated mostly mechnically by performing the following steps:
 - sed -i '' -E -e 's/defined\(OS_/BUILDFLAG(IS_/g' \
                -e 's%([ !])OS_([A-Z]+)%\1BUILDFLAG(IS_\2)%g' \
       $(git grep -l 'OS_'
         '**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm')
 - sed -i '' -e 's/#ifdef BUILDFLAG(/#if BUILDFLAG(/' \
       $(git grep -l '#ifdef BUILDFLAG('
         '**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm')
 - gsed -i -z -E -e \
       's%(.*)#include "%\1#include "build/buildflag.h"\n#include "%' \
       $(git grep -l 'BUILDFLAG(IS_'
         '**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm')
 - Spot checks to move #include "build/buildflag.h" to the correct parts
   of files.
 - sed -i '' -E -e \
       's%^(#include "build/buildflag.h")$%#include "build/build_config.h"\n\1%' \
       $(grep -L '^#include "build/build_config.h"$'
         $(git grep -l 'BUILDFLAG(IS_'
           '**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm'))
 - Add “clang-format off” around tool usage messages.
 - git cl format
 - Update mini_chromium to 85ba51f98278 (intermediate step).
   TESTING ONLY).
 - for f in $(git grep -l '^#include "build/buildflag.h"$'
              '**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm'); do \
       grep -v '^#include "build/buildflag.h"$' "${f}" > /tmp/z; \
       cp /tmp/z "${f}"; done
 - git cl format
 - Update mini_chromium to 735143774c5f (intermediate step).
 - Update mini_chromium to f41420eb45fa (as checked in).
 - Update mini_chromium to 6e2f204b4ae1 (as checked in).

For ease of review and inspection, each of these steps is uploaded as a
new patch set in a review series.

This includes an update of mini_chromium to 6e2f204b4ae1:

f41420eb45fa Use BUILDFLAG for OS checking
6e2f204b4ae1 Include what you use: string_util.h uses build_config.h

Bug: chromium:1234043
Change-Id: Ieef86186f094c64e59b853729737e36982f8cf69
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3400258
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
2022-01-19 20:21:19 +00:00
Joshua Peraza
52ff1accbb linux: Fix locating modules with multiple mappings from offset 0
The general strategy used by Crashpad to determine loaded modules is to
read the link_map to get the addresses of the dynamic arrays for all
loaded modules. Those addresses can then be used to query the MemoryMap
to locate the module's mappings, and in particular the base mapping
from which Crashpad can parse the entire loaded ELF file.

ELF modules are typically loaded in several mappings with varying
permissions for different segments. The previous strategy used to find
the base mapping for a module was to search backwards from the mapping
for the dynamic array until a mapping from file offset 0 was found for
the same file. This fails when the file is mapped multiple times from
file offset 0, which can happen if the first page of the file contains
a GNU_RELRO segment.

This new strategy queries the MemoryMap for ALL mappings associated
with the dynamic array's mapping, mapped from offset 0. The consumer
(process_reader_linux.cc) can then determine which mapping is the
correct base by attempting to parse a module at that address and
corroborating the PT_DYNAMIC or program header table address from the
parsed module with the values Crashpad gets from the link_map or
auxiliary vector.

Bug: crashpad:30
Change-Id: Ibfcbba512e8fccc8c65afef734ea5640b71e9f70
Reviewed-on: https://chromium-review.googlesource.com/1139396
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
2018-07-26 15:33:15 +00:00
Mark Mentovai
107fb76317 mac: Handle _dyld_get_all_image_infos() not being available on 10.13
_dyld_get_all_image_infos() was only used in test code in Crashpad.

This addresses two related problems.

When running on 10.13 or later, _dyld_get_all_image_infos() is not
available. It appears to still be implemented in dyld, but its symbol is
now private. This was always known to be an “internal” interface. When
it’s not available, fall back to obtaining the address of the process’
dyld_all_image_infos structure by calling task_info(…, TASK_DYLD_INFO,
…). Note that this is the same thing that the code being tested does,
although the tests are not rendered entirely pointless because the code
being tested consumes dyld_all_image_infos through its own
implementation of an out-of-process reader interface, while the
dyld_all_image_infos data obtained by _dyld_get_all_image_infos() is
handled strictly in-process by ordinary memory reads. This is covered by
bug 187.

When building with the 10.13 SDK, no _dyld_get_all_image_infos symbol is
available to link against. In this case, access the symbol strictly at
runtime via dlopen() if it may be available, or when expecting to only
run on 10.13 and later, don’t even bother looking for this symbol. This
is covered by part of bug 188.

Bug: crashpad:185, crashpad:187, crashpad:188
Change-Id: Ib283e070faf5d1ec35deee420213b53ec24fb1d3
Reviewed-on: https://chromium-review.googlesource.com/534633
Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-06-14 15:08:05 +00:00