On Sun, Jun 21, 2009 at 11:20 AM, John David Anglin<dave@xxxxxxxxxxxxxxxxxx> wrote: > We never figured out why the fault actually occurred (Kyle got busy). > It seems like there is a problem with the address mapping during signals. > However, there was some rebuilds in the above and I'm not sure the > analysis is correct. However, I'm sure the problem isn't with > __canonicalize_funcptr_for_compare. Hoccam's razor. It's a gcc bug. The arg0 to __c_f_f_c is being clobbered by the previous call. Rearrangeing the if-the-else cases into a set if cases fixes the clobbering of arg0 and fixes strace. The move of the fptr into r26 is moved before the call to umove, then umove clobbers r26, then __c_f_f_c is called and crashes. > So, the quick fix to get strace going is to rebuild casting the function > pointers to long. However, I think you will find that it has other problems. > You might have more success with the old version that Kyle patched a > year or so ago (posted in debian people). Randolph was working on a program > called atrace. I tried it but didn't have much luck with it. The quick fix is to reorganize the if-then-else statement. > PS: Hows NPTL comming? The implementation is done. The testsing shows no regressions. The custom compat testsuite I wrote also passes every test. Unfortunately last night I was up late working and I managed to both erase (be careful of bind mounts) half of my custom compat testsuite and the chroot I was going to use for more advanced testing. On todays schedule is to rebuild the chroot and test gnome using vnc4server with the new libs. At a later date I'll have to rewrite the missing pieces of the custom compat testsuite. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
