https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
Phil Miller <unmobile at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |unmobile at gmail dot com
--- Comment #38 from Phil Miller <unmobile at gmail dot com> ---
(In reply to Dmitry Vyukov from comment #34)
> I propose to close this as obsolete. Or does somebody see any actionable
> items here?
> Non-pie binaries are supported by tsan now. Non-aslr (0x55555) are not.
I have a definite real-world use case for ThreadSanitizer with ASLR disabled,
which I would really like to see supported. I'm happy to help in testing or
hacking, with pointers in the right direction.
Potentially horrifying details:
I work on a system for distributed-memory parallel programming called Charm++.
One of the features of our system is an ability to migrate user-level threads
across processes and hardware nodes. This lets us provide functionality like
load balancing, communication optimization, and fault tolerance with low
overhead and fine granularity.
To do this 'nicely', without our users having to write huge amounts of very
finicky serialization code, we implement a technique called 'isomalloc'. In
isomalloc, each thread is allocated in a chunk of virtual address space that is
unique across the entire distributed set of processes. Any memory allocations
by that thread are served from this chunk. When we want to migrate a thread, we
can just copy the allocated bits of that chunk, including its stack, from one
process to another, and all the pointers within will remain valid.
Isomalloc works best when we can assure it as large a range of common,
unoccupied virtual address space as possible. Thus, it's much happier when ASLR
is disabled.
Our runtime system supports a shared-memory multi-threading mode that allows
message passing by pointer within each process. Several libraries on top of the
RTS also exploit shared memory to reduce memory footprint and/or improve
performance. So, we and our users really benefit from being able to use
ThreadSanitizer to help debug our code. For instance, you can see our tracking
bug for issues in our code code that have been detected using tsan so far:
https://charm.cs.illinois.edu/redmine/issues/535
Tie that all together, and we really want to see tsan working with non-ASLR.
I've just tested the patch in https://bugzilla.kernel.org/show_bug.cgi?id=66721
against Linux 3.19-rc1, and found that it doesn't (no longer?) solve this
issue.
I tried compiling my code as non-PIE to hack around this issue. GCC will accept
"-fsanitize=thread -fPIC -shared" instead of "-fsanitize=thread -fPIE -pie" to
compile and link successfully. However, any attempts to run the resulting
binary result in a segfault. Per earlier requests, here's /proc/.../maps for
that process:
555555554000-555555555000 r-xp 00000000 08:07 2072846
/home/phil/pie
555555754000-555555755000 rw-p 00000000 08:07 2072846
/home/phil/pie
7ffff7ffb000-7ffff7ffd000 r-xp 00000000 00:00 0 [vdso]
7ffff7ffd000-7ffff7fff000 r--p 00000000 00:00 0 [vvar]
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0
[stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]
If there's some other way to build as non-PIE that will let tsan work with ASLR
disabled, I'm happy to get a workaround, as long as it's something I can
document for our users.
