port-tsan on ARMv7 32 bit

[arunabh choudhary]

hi i am looking to run tsan in my ARMv7 32 bit architecture. i have 2 queries.

1. Is the "difficulty for running in 32-bit architecture" because of the Physical Address Extension (PAE) and because of simplicity of use it does not support 32 bits?

2. if i need to port it into 32 bit ARM, is it possible?, if it is possible do i need to do anything else along with porting "tsan_rtl_amd64.S" assembly code to ARM assemble code?
any help will be appreciated . thanks.

[Dmitry Vyukov]

Hi Arunabh,

Porting current tsan to a 32-bit architecture is pretty much
unfeasible. It is memory hungry (increases memory consumption by at
least 5x) and requires a huge continuous range of virtual address
space.

But you potentially can run your app on a beefy linux/amd64 machine
and verify it with tsan there.

[arunabh choudhary]

hi Dmitry,

thanks for the quick response but the application supports only ARM architecture. can we port tsan to 64-bit ARM. as i mentioned if i am able to turn the assembly code in "tsan_rtl_amd64.S" file to ARM assemble. would it be possible. is there any possibility if i can cross compile my code for ARM target in a 64bit linux x86 but i will still be needing the tsan libraries to be cross compiled for ARM -64 bit target. can i do that. thanks

[Dmitry Vyukov]

There is currently ongoing work to port tsan to aarch64 linux and android.
Here is one reference:
http://reviews.llvm.org/D11484

I never tried to run tsan on aarch64, but I've been told that this
part is not finished.
If you are interested in the status, you can search the llvm-dev mailing list:
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
or ask there directly.



On Thu, Aug 20, 2015 at 8:23 PM, arunabh choudhary

> --
> You received this message because you are subscribed to the Google Groups
> "thread-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to thread-sanitiz...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[arunabh choudhary]

Hi Dmitry,

Thank you again for your quick response.

I am thinking to port tsan into ARM 32 bits architecture by de coupling events-log generation and actual data-race-detection algorithms. I like to know your thoughts on it. My idea is as follows.

 

1. Define memory layout for ARM 32 bits

2. Use tsan to log all events of interests (memory read, write, synchronization) into a file.

3. After execution is finished, analyze the event-log file for the data race using suitable algorithm.

 

 thanks.

[Dmitry Vyukov]

On Fri, Aug 21, 2015 at 12:59 PM, arunabh choudhary
<arunab...@gmail.com> wrote:
> Hi Dmitry,
>
> Thank you again for your quick response.
>
> I am thinking to port tsan into ARM 32 bits architecture by de coupling
> events-log generation and actual data-race-detection algorithms. I like to
> know your thoughts on it. My idea is as follows.
>
>
>
> 1. Define memory layout for ARM 32 bits
>
> 2. Use tsan to log all events of interests (memory read, write,
> synchronization) into a file.
>
> 3. After execution is finished, analyze the event-log file for the data race
> using suitable algorithm.

That will work. We actually had such "offline" mode in the old
Valgrind-based tsan.
For that you will need to implement a separate runtime that implements
__tsan_read/write/func_entry/exit and interceptors that merely log
events into a file. And then you will need to implement an "offline"
tsan that reads the event log and feeds into tsan state machine.
Three potentially problematic moments:
1. I am not sure that it will be possible to directly reuse
tsan_interceptors for event collection; there can be assumption that
race detection happens online; or there can be very tight coupling
between the interceptors and state machine. That may require some
refactoring of interceptors and how they interact with the state
machine.
2. Similar issue for the state machine (tsan_rtl.cc); there can be
assumption that it runs online.
3. Scalable multi-threaded event collection may be non-trivial. You
want to allows threads to log in parallel for performance, but at the
same time you need to properly interleave per-thread event buffers on
synchronization events to preserve consistent order of events.
If you are serious about this, then please share the design and
prototypes with us early. The "offline" mode would be a useful
addition to tsan, but it needs to be implemented in a clean way (not
like tons of ifdefs sprinkled throughout tsan codebase).

Thank you