This is an archive of the discontinued LLVM Phabricator instance.

[tsan] Enable 48-bit VMA support on aarch64
ClosedPublic

Authored by zatrazz on Jul 20 2016, 2:28 PM.

Details

Summary

This patch adds 48-bits VMA support for tsan on aarch64. As current
mappings for aarch64, 48-bit VMA also supports PIE executable. This
limits the mapping mechanism because the PIE address bits
(usually 0aaaaXXXXXXXX) makes it harder to create a mask/xor value
to include all memory regions. I think it is possible to create a
large application VAM range by either dropping PIE support or tune
current range.

The patch also remove the heap accounting and checking if the architecture
does not uses 64-bit size allocator. This is due the fact heap VAM
range is used only for the allocator on TSAN, so this allows use the
range for application usage.

It also changes slight the way addresses are packed in SyncVar structure:
previously it assumes x86_64 as the maximum VMA range. Since ID is 14 bits
wide, shifting 48 bits should be ok.

Tested on x86_64, ppc64le and aarch64 (39 and 48 bits VMA).

Diff Detail

Event Timeline

zatrazz updated this revision to Diff 64764.Jul 20 2016, 2:28 PM
zatrazz retitled this revision from to [tsan] Enable 48-bit VMA support on aarch64.
zatrazz updated this object.
zatrazz added a project: Restricted Project.
zatrazz added a subscriber: llvm-commits.
eugenis removed a reviewer: eugenis.
dvyukov added inline comments.Jul 26 2016, 7:47 AM
lib/tsan/rtl/tsan_platform.h
197

I see that kHeapMemBeg/End situation is quite inconsistent across mappings. E.g. aarch64/42vma reserves a non-empty range for heap:

static const uptr kHeapMemBeg    = 0x3e000000000ull;
static const uptr kHeapMemEnd    = 0x3f000000000ull;

But it is actually unused.

I see ways to get situation under control:

  1. Either guard the remaining uses of these constants in this file by TSAN_USE_ALLOCATOR64, and then remove definitions of the constants for configurations that don't use 64-bit allocator.
  2. Or define kHeapMemBeg==kHeapMemEnd for such arches and do not other changes. Why did you guard all uses of these constants by SANITIZER_CAN_USE_ALLOCATOR64? I think ProtectRange should handle an empty range, CheckUserRegions should handle them as well. Can we remove all these ifdefs?
485

drop "on tsan"
everything in tsan/* is about tsan

486

s/used/use/

486

s/an user/a user/

lib/tsan/rtl/tsan_platform_posix.cc
145 ↗(On Diff #64764)

#if SANITIZER_CAN_USE_ALLOCATOR64 is a wrong condition for tsan, it uses a different condition. Please create a new define TSAN_USE_ALLOCATOR64 for tsan.

lib/tsan/rtl/tsan_sync.h
52–53

Please also update this comment.

zatrazz updated this revision to Diff 65604.Jul 26 2016, 2:34 PM

I simplified the patch a bit by removing the allocator64 define usage. I also updated the sync comments.

dvyukov accepted this revision.Jul 27 2016, 7:46 AM
dvyukov edited edge metadata.

Much cleaner now. Thanks. LGTM

This revision is now accepted and ready to land.Jul 27 2016, 7:46 AM
zatrazz closed this revision.Jul 29 2016, 7:00 AM