Now that the sanitizer_common interface for MmapNoAccess / MmapFixed have been refactored to allow a more OO-esque access pattern, update the Fuchsia mmap implementation to take advantage of this. Previously MmapNoAccess / MmapFixed relied on a global allocator_vmar, since the sanitizer_allocator only called MmapNoAccess once. Now, we create a new VMAR per ReservedAddressRange object. This allows the sanitizer allocator to work in tandem with the Scudo secondary allocator. This is part 4 of a 4 part changeset: * part 1 https://reviews.llvm.org/D38593 * part 2 https://reviews.llvm.org/D38592 * part 3 https://reviews.llvm.org/D38593
|242 ↗||(On Diff #117868)|
Could be DCHECK_EQ, since it should be impossible.
|248 ↗||(On Diff #117868)|
Pass name, not a constant string.
|272 ↗||(On Diff #117868)|
This should not exist here. The caller of Init supplies the name and that should be stored and used in all cases.
|300 ↗||(On Diff #117868)|
static_cast or no cast at all, since uptr and uintptr_t are always actually the same type.
Real patch; updated with changes from patches 1-3, and ofc responded to initial comments/feedback.
Few comments inline.
Might want to lint the source, it seems all over.
I am assuming the other platforms are going to complain about a private member not used?
I don't think nullptr is a valid error return value here.
Doesn't that fit on 1 line?
The initialization doesn't make sense. It's overwritten by the call. You've already asserted that the value is ZX_HANDLE_INVALID.
Why not call it 'vmar'?
This code uses space before *. Just put the whole file through clang-format.
I don't think there's really any need for this cast. Default integer conversions are fine.
The only caller that accepts any failure return value is MapWithCallback, and it checks for a zero result.
is it ok to use a pragma to suppress the "private member not used" complaint (as i've done here)?
Windows seems to be the only big consummer of pragmas in sanitizer_common.
Yes, I think it's better to initialize it in all implementations than to add another pragma.