Fix for 2.6.26 ptrace crash
PATCH 1/1 Fix for 2.6.26 ptrace crash
I believe I figured out the ptrace crash that showed up with 2.6.26, thanks to Toralf Förster.
The patch is below.
I have one confirmation that this fixes the problem - I'd like a few more just to be sure.
Jeff
Signature · 38 lines
Work email - jdike at linux dot intel dot com Index: linux-2.6.22/arch/um/include/init.h =================================================================== --- linux-2.6.22.orig/arch/um/include/init.h 2008-02-18 11:53:50.000000000 -0500 +++ linux-2.6.22/arch/um/include/init.h 2008-07-20 18:06:35.000000000 -0400 @@ -45,6 +45,8 @@ typedef void (*exitcall_t)(void); # define __section(S) __attribute__ ((__section__(#S))) #endif +#if __GNUC__ == 3 + #if __GNUC_MINOR__ >= 3 # define __used __attribute__((__used__)) #else @@ -52,6 +54,12 @@ typedef void (*exitcall_t)(void); #endif #else +#if __GNUC__ == 4 +# define __used __attribute__((__used__)) +#endif +#endif + +#else #include <linux/compiler.h> #endif /* These are for everybody (although not all archs will actually ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Hello,
I also had the crash with a lot of zeros in a vertical line with kernel 2.6.26, I was sad then.
But I am now happy, I applied the patch:
bash-3.1# cd linux-2.6.26
bash-3.1# patch -p1 < ../jeff.patch
patching file arch/um/include/init.h
Hunk #1 succeeded at 45 with fuzz 2.
Hunk #2 succeeded at 54 with fuzz 1.
And my 2.6.26 uml machine worked!!
All this to say: I confirm the patch worked for me too.
Regards
Quoted 10 lines · Jeff Dike
I believe I figured out the ptrace crash that showed up with 2.6.26, thanks to Toralf Förster.
The patch is below.
I have one confirmation that this fixes the problem - I'd like a few more just to be sure.
Jeff
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Thanks, the patch worked for me too.
As an aside, may be u would want to sync with mainline:
http://lkml.org/lkml/2007/5/3/460
which would solve the problem Boaz posed as well?
(the patch above seemed to indicate a problem of post-3.4 vs pre-3.4 GCC:
http://www.gnu.org/software/gcc/gcc-3.4/changes.html
but your patch indicated something to do with 4.x GCC vs pre-3.4 GCC?)
Sorry if I don't get it correctly :-).
Quoted 40 lines · Jeff Dike
I believe I figured out the ptrace crash that showed up with 2.6.26, thanks to Toralf Förster.
The patch is below.
I have one confirmation that this fixes the problem - I'd like a few more just to be sure.
Jeff
--
Work email - jdike at linux dot intel dot comIndex:
linux-2.6.22/arch/um/include/init.h
===================================================================arch/um/include/init.h 2008-07-20 18:06:35.000000000 -0400 renamed from arch/um/include/init.h 2008-02-18 11:53:50.000000000 -0500 +8
-0@@ -45,6 +45,8 @@ typedef void (*exitcall_t)(void); # define __section(S) __attribute__ ((__section__(#S))) #endif +#if __GNUC__ == 3 + #if __GNUC_MINOR__ >= 3 # define __used __attribute__((__used__)) #else@@ -52,6 +54,12 @@ typedef void (*exitcall_t)(void); #endif #else +#if __GNUC__ == 4 +# define __used __attribute__((__used__)) +#endif +#endif + +#else #include <linux/compiler.h> #endif /* These are for everybody (although not all archs will actually
Signature · 12 lines
Regards, Peter Teoh ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines · Boaz Harrosh
I'm not sure I fully understand. Could you please explain what you found.
arch/um/include/init.h copies enough definitions from linux/compiler.h and linux/init.h to implement initcall and exitcall et al. It can't include the kernel headers because it's included in userspace files, and libc and kernel headers don't mix.
What happened was that I copied enough to make a distinction between gcc 3.3 and higher vs lower than 3.3 (for the latter, the kernel defines __used as attribute(__unused) for some reason).
However, since my ifdefs weren't looking at the major version, these definitions also held for gcc 4.x. And when I added unit-at-a-time, the __unused started being taken seriously, and UML libc-side initcalls were thrown out.
Quoted 2 lines
Why is it that with same compiler, some systems had a problem and some did not? is it .config related?
I have no idea. When Ulrich Drepper first hit this, he and I had the same base system, same architecture, same toolchain, same config, and I didn't see it.
I've upgraded since then, so I can't test in the same environment, but when I add the bug back in such that it hits with gcc 4.3, I get the crash.
So, this is very mysterious.
Quoted 5 lines
Also I would prefer if the:
#define __used __attribute__((__used__))would get an #if ((__GNUC__* 100 +
__GNUC_MINOR__) >= 303 ) of its own because other wise this problem will return when gcc hits 5. Just as it returned now.
I don't see the point - this is all wrapped in __GNUC__ == 3 or 4. As for gcc 5, linux/compiler has this to say:
#else
# error Sorry, your compiler is too old/not recognized. #endif
So the kernel totally won't build with gcc 5.
Jeff
Signature · 11 lines
Work email - jdike at linux dot intel dot com ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel