diff options
author | Dan Liew <dan@su-root.co.uk> | 2018-12-28 19:30:51 +0000 |
---|---|---|
committer | Dan Liew <dan@su-root.co.uk> | 2018-12-28 19:30:51 +0000 |
commit | 8c11fb3ed419a8c48f0f36af6e0a621aa75be320 (patch) | |
tree | 1725a89afdd72dd48f0cd41cb27940833c60f19e /llvm/lib/Support/Error.cpp | |
parent | bae11e79990a97133cfced28796a5695d823015c (diff) | |
download | llvm-8c11fb3ed419a8c48f0f36af6e0a621aa75be320.zip llvm-8c11fb3ed419a8c48f0f36af6e0a621aa75be320.tar.gz llvm-8c11fb3ed419a8c48f0f36af6e0a621aa75be320.tar.bz2 |
Introduce `LocalAddressSpaceView::LoadWritable(...)` and make the `Load(...)` method return a const pointer.
Summary:
This is a follow-up to r346956 (https://reviews.llvm.org/D53975).
The purpose of this change to allow implementers of the
`AddressSpaceView` to be able to distinguish between when a caller wants
read-only memory and when a caller wants writable memory. Being able
distinguish these cases allows implementations to optimize for the
different cases and also provides a way to workaround possible platform
restrictions (e.g. the low level platform interface for reading
out-of-process memory may place memory in read-only pages).
For allocator enumeration in almost all cases read-only is sufficient so
we make `Load(...)` take on this new requirement and introduce the
`LoadWritable(...)` variants for cases where memory needs to be
writable.
The behaviour of `LoadWritable(...)` documented in comments are
deliberately very restrictive so that it will be possible in the future
to implement a simple write-cache (i.e. just a map from target address
to a writable region of memory). These restrictions can be loosened in
the future if necessary by implementing a more sophisticated
write-cache.
rdar://problem/45284065
Reviewers: kcc, cryptoad, eugenis, kubamracek, george.karpenkov
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D54879
llvm-svn: 350136
Diffstat (limited to 'llvm/lib/Support/Error.cpp')
0 files changed, 0 insertions, 0 deletions