|
From: Maynard J. <may...@us...> - 2010-12-14 00:42:57
|
Julian Seward wrote: > > How do you know the generated code is incorrect? Do you have more > info on this? I've attached two files showing the assembly code for machine_get_hwcaps for the good case (valgrind built with gcc 4.1.2) and the bad case (valgrind built with gcc 4.5.2). I ran this code on a POWER5, so it should fail the VMX check (using 'vor' instruction), where the __builtin_setjmp is at line 789 of coregrind/m_machine.c. You'll notice that in the good case, code is generated to branch to line 790 on failure or to line 797 on success. The generated code in the bad case does nothing like it's supposed to. > > Does the problem happen for ppc32, or does it only appear in > 64-bit mode? Both modes. -Maynard > > J > > On Friday, December 10, 2010, Maynard Johnson wrote: >> I've found that Valgrind may segfault in >> coregrind/m_machine.c:VG_(machine_get_hwcaps) under certain conditions: - >> Running on a processor where one of the capability checks will fail (e.g., >> IBM POWER5, checking for Altivec) - Valgrind was built with gcc 4.4.4 or >> later >> >> The generated code is apparently incorrect, but we got no joy when our >> resident gcc person reported this to other gcc community folk. We were >> told that these functions are for internal gcc use only -- and also that >> doing a longjmp out of a signal handler is "undefined" by the POSIX >> standard. So far, I've only seen problems occur in cases where the >> longjmp is performed out of a signal handler. >> >> I was able to come up with a patch to eliminate the use of these functions >> where it was causing problems on my older POWER systems, and I will open a >> bugzilla and attach that patch. But there are some other places where >> these functions are used (listed below). Someone familiar with ARM should >> probably take a look at the issue for that architecture, since those cases >> also use signal handlers like the problematic ppc64 cases I am fixing. >> But there are some architecture-independent uses that need to be >> investigated, as well. My sense is that the cases that do NOT involve >> signal handlers are OK for now -- based on my testing using gcc 4.4.4. >> >> Examples of __builtin_set[long]jmp with signal handlers >> ---------------------------------------------------- >> - coregrind/m_machine.c: ppc64 and arm >> - exp-ptrcheck/tests (several users of '#define TTT' which makes use of >> __builtin_setjmp) >> - memcheck/tests (badjmup2.c) >> - memcheck/mc_leakcheck.c >> >> Examples of __builtin_set[long]jmp without signal handlers >> ---------------------------------------------------- >> - coregrind/m_debuginfo/readdwarf.c >> - coregrind/m_scheduler/scheduler.c >> >> Regards, >> -Maynard >> >> >> --------------------------------------------------------------------------- >> --- Oracle to DB2 Conversion Guide: Learn learn about native support for >> PL/SQL, new data types, scalar functions, improved concurrency, built-in >> packages, OCI, SQL*Plus, data movement tools, best practices and more. >> http://p.sf.net/sfu/oracle-sfdev2dev >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |