[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128 Kostya Serebryany changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Kostya Serebryany 2013-02-13 10:55:48 UTC --- This particular problem (with futex headers) should be fixed by the last merge (r196009)
[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128 --- Comment #13 from Jakub Jelinek 2013-02-11 15:54:17 UTC --- Perhaps instead of global vars defined outside of libasan (which e.g. requires GOT accesses to those vars in libasan), it might be better to have the scale and offset as arguments of __asan_init? Then you could easily test at runtime, whether all compilation units agree on the same offset/scale, and complain if they don't. Then __asan_mapping_offset and __asan_mapping_scale or how are the vars called could be hidden attribute, used with PC relative addressing and avoid one extra indirection, and more importantly have better runtime checking of mismatches.
[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128 --- Comment #12 from Jakub Jelinek 2013-02-11 13:13:14 UTC --- (In reply to comment #11) > > We need more than that. E.g. ppc64 asan is very much broken in the gcc > > tree, > > that is fixed in upstream libasan already, right? > > Last time I tried, basic tests passed on ppc64 with 44 address space (did not > checke with 46 AS). http://ppc.koji.fedoraproject.org/packages/gcc/4.8.0/0.10.fc19/data/logs/ppc64/build.log shows lots of failures. Guess it is possible those boxes use 46-bit AS. > Ok, I'll do the merge after the scanf stuff is in. Thanks. > > BTW, any progress with the 0x7fff8000 shadow offset for x86_64? > > Not yet. Hopefully will try it this week. Looking forward to those results. > > > If it looks > > good benchmark-wise, I think it would be better if we switched the ASAN > > x86_64 > > ABI for GCC sooner (read, before 4.8) than have one asan ABI for 4.8 built > > objects and another one for 4.9 built objects (which is still possible that > > it > > will happen, but it wouldn't hurt to avoid that). > > Agree. How much time do we have? Not too much time, I guess if the real change on the gcc + libsanitizer side will be tweaking a few constants, it can be done within next few weeks, but preferably in February. A full libsanitizer merge should be this or next week, so that we have time to handle with any fallout of that (but at that point already just selective backports).
[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128 --- Comment #11 from Kostya Serebryany 2013-02-11 12:58:07 UTC --- > We need more than that. E.g. ppc64 asan is very much broken in the gcc tree, > that is fixed in upstream libasan already, right? Last time I tried, basic tests passed on ppc64 with 44 address space (did not checke with 46 AS). > > I'd think we should just do one more llvm -> libsanitizer merge soon (after > the > scanf stuff is resolved?). Ok, I'll do the merge after the scanf stuff is in. > A slight complication is that asan_test.cc got > split into smaller tests, but even for GCC it will be worthwhile to have fewer > smaller tests I guess, we'll just need to add the wrappers. > > BTW, any progress with the 0x7fff8000 shadow offset for x86_64? Not yet. Hopefully will try it this week. > If it looks > good benchmark-wise, I think it would be better if we switched the ASAN x86_64 > ABI for GCC sooner (read, before 4.8) than have one asan ABI for 4.8 built > objects and another one for 4.9 built objects (which is still possible that it > will happen, but it wouldn't hurt to avoid that). Agree. How much time do we have?
[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128 --- Comment #10 from Jakub Jelinek 2013-02-11 12:08:11 UTC --- (In reply to comment #9) > (In reply to comment #8) > > Requires a merge as far as I can see. Important enough build issue. > > I am reluctant to do another full merge so close to 4.8 -- we have too many > intrusive changes in upstream trunk. > > Jakub, WDYT? > Maybe we just apply http://llvm.org/viewvc/llvm-project?rev=173933&view=rev > once 4.8 branches out? > (Not sure if the gcc development process works this way...) We need more than that. E.g. ppc64 asan is very much broken in the gcc tree, that is fixed in upstream libasan already, right? I'd think we should just do one more llvm -> libsanitizer merge soon (after the scanf stuff is resolved?). A slight complication is that asan_test.cc got split into smaller tests, but even for GCC it will be worthwhile to have fewer smaller tests I guess, we'll just need to add the wrappers. BTW, any progress with the 0x7fff8000 shadow offset for x86_64? If it looks good benchmark-wise, I think it would be better if we switched the ASAN x86_64 ABI for GCC sooner (read, before 4.8) than have one asan ABI for 4.8 built objects and another one for 4.9 built objects (which is still possible that it will happen, but it wouldn't hurt to avoid that).
[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128 --- Comment #9 from Kostya Serebryany 2013-02-11 11:54:46 UTC --- (In reply to comment #8) > Requires a merge as far as I can see. Important enough build issue. I am reluctant to do another full merge so close to 4.8 -- we have too many intrusive changes in upstream trunk. Jakub, WDYT? Maybe we just apply http://llvm.org/viewvc/llvm-project?rev=173933&view=rev once 4.8 branches out? (Not sure if the gcc development process works this way...)
[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128 Richard Biener changed: What|Removed |Added Keywords||build Priority|P3 |P1 --- Comment #8 from Richard Biener 2013-02-08 15:16:59 UTC --- Requires a merge as far as I can see. Important enough build issue.
[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #7 from Dmitry Vyukov 2013-01-30 15:32:02 UTC --- Fixed upstream: http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_linux.cc?r1=173933&r2=173932&pathrev=173933
