This is an archive of the discontinued LLVM Phabricator instance.

[Tsan] Add support for FreeBSD memory layout
AbandonedPublic

Authored by kutuzov.viktor.84 on Oct 9 2014, 12:08 PM.

Details

Diff Detail

Event Timeline

kutuzov.viktor.84 retitled this revision from to [Tsan] Add support for FreeBSD memory layout.
kutuzov.viktor.84 updated this object.
kutuzov.viktor.84 edited the test plan for this revision. (Show Details)
kutuzov.viktor.84 added reviewers: kcc, samsonov, glider.
kutuzov.viktor.84 added subscribers: Unknown Object (MLST), emaste.

Fixed comments, indentation and TSAN_GO dependencies.

Fixed placement of curly braces.

emaste added inline comments.Oct 22 2014, 1:45 PM
lib/tsan/rtl/tsan_platform_linux.cc
12

Should be Linux- and FreeBSD-specific code. I think - and would be useful to explain why the FreeBSD code is in the _linux.cc file.

267

It's rather confusing for these constants to be named kLinux... for the FreeBSD-specific code.

Would it be OK for these to be kLowShadowBeg etc.?

323

Why is this one a bare constant here rather than some k constant?

dvyukov edited edge metadata.Oct 23 2014, 1:27 AM

samsonov added a reviewer: dvyukov.

Alexey, this did not work. I did not receive any email.

Do you essentially want to support non-pie binaries where something is mapped in the first 64GB? Is it the only difference with the current linux mapping?
If it's the only difference, then it's time for me to implement non-pie support finally.

Add me to tsan reviews, I am the author of tsan.

lib/tsan/rtl/tsan_platform.h
50

please use the same format as entries above -- the second address is exclusive, that is:
0000 0000 0000 - 0000 0100 0000

58

here is something wrong, the previous line already covers this range

60

what's at 5000 0000 0000 - 6000 0000 0000 ?

kutuzov.viktor.84 edited edge metadata.

Fixed to reflect the notes and suggestions from Dmitry and Ed.

It's rather confusing for these constants to be named kLinux... for the FreeBSD-specific code.

Dmitry, do you think we should generalize these names?

Do you essentially want to support non-pie binaries where something is mapped in the first 64GB? Is it the only difference with the current linux mapping?
If it's the only difference, then it's time for me to implement non-pie support finally.

I didn't dig it up yet, but given it is supported on Linux, we certainly will consider support it on FreeBSD as well.

I didn't dig it up yet, but given it is supported on Linux, we certainly will consider support it on FreeBSD as well.

I am asking about what this change does. Does it just allow user data in the first 64GBs of memory?

I am asking about what this change does. Does it just allow user data in the first 64GBs of memory?

Yes, the only difference is that we have user data on both ends of the memory map. If you need similar changes to support non-PIEs on Linux, then indeed it would be good to implement some generic mechanism to address both the tasks.

kutuzov.viktor.84 abandoned this revision.Oct 27 2014, 4:22 AM

Abandoned in favor of rL220571 and D5990.