|
From: Maynard J. <may...@us...> - 2010-12-10 17:50:03
|
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 |