http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #18 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #16)
> > Kernel is free to load PIE at ANY address it wants. But
> > you can specify where to load PIE via a linker switch
> >
> > -Ttext-segment 0x8500
> >
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #17 from Kostya Serebryany ---
> already, but don't remember where exactly.
Please let's move the discussion about non-PIE here:
https://code.google.com/p/thread-sanitizer/issues/detail?id=5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #16 from Kostya Serebryany ---
> Kernel is free to load PIE at ANY address it wants. But
> you can specify where to load PIE via a linker switch
>
> -Ttext-segment 0x8500
>
> to tell kernel to load PIE to a specific address.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #15 from Jakub Jelinek ---
What I mean, unlike asan where the shadow memory shift and base is part of the
ABI, in tsan, while performance sensitive, the MemToShadow is still library
implementation detail. So, I think it shouldn't be t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #14 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #11)
> > 4000-5000 r-xp 08:11 34221424
> > /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/testsuite/atomic_stack.exe
>
> So,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #13 from Dmitry Vyukov ---
And what if you enable randomization?
> Have any attempt for saner tsan shadow memory mapping be done in the last
> year?
No, there were no such attempts.
But, yes, it would be nice if tsan supports no-ASR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #12 from H.J. Lu ---
For some reason, tsan tests aren't run on 6GB machine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #11 from Kostya Serebryany ---
> 4000-5000 r-xp 08:11 34221424
> /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/testsuite/atomic_stack.exe
So, the executable is loaded into 4000, wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #10 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #3)
> (In reply to H.J. Lu from comment #0)
> > On a Linux/x86-64 machine with 4GB RAM, I got failures like:
> >
> > FAIL: c-c++-common/tsan/atomic_stack.c -O0 output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #9 from Kostya Serebryany ---
(In reply to H.J. Lu from comment #6)
> I got those failures on this machine:
Admittedly, I never ran tsan tests on a 4Gb machine.
Does clang's tsan also fail there?
Can you show /proc/self/maps of the f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
Kostya Serebryany changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Last reconfirmed|2013-1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #7 from H.J. Lu ---
On failed machine:
[hjl@gnu-ivb-1 ~]$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #5 from Jakub Jelinek ---
Have any attempt for saner tsan shadow memory mapping be done in the last year?
I mean, there were some PRs or mailing list threads about it being worth to
support also non-PIE executables etc., understandably
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #4 from Kostya Serebryany ---
(In reply to Dmitry Vyukov from comment #2)
> It seems that this kernel has ASLR disabled, so kernel maps libraries at
> 0x55. Tsan does not support this ATM.
BTW, the situation with tsan's shadow became w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #3 from Kostya Serebryany ---
(In reply to H.J. Lu from comment #0)
> On a Linux/x86-64 machine with 4GB RAM, I got failures like:
>
> FAIL: c-c++-common/tsan/atomic_stack.c -O0 output pattern test, is FATAL:
> ThreadSanitizer can n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #2 from Dmitry Vyukov ---
It seems that this kernel has ASLR disabled, so kernel maps libraries at 0x55.
Tsan does not support this ATM.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #1 from Jakub Jelinek ---
BTW, the tsan.exp tests don't seem to be as cheap as was claimed during the
patch submission, I'd prefer to at least throttle the torture options down to
say -O0 and -O2 rather than so many different variants
18 matches
Mail list logo
