Diff Detail
Event Timeline
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? |
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: | |
58 | here is something wrong, the previous line already covers this range | |
60 | what's at 5000 0000 0000 - 6000 0000 0000 ? |
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.
please use the same format as entries above -- the second address is exclusive, that is:
0000 0000 0000 - 0000 0100 0000