From: Jeff D. <jd...@ad...> - 2008-07-21 15:47:33
|
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 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 |
From: vincent-perrier <vin...@cl...> - 2008-07-21 20:24:44
|
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 On Mon, 2008-07-21 at 11:46 -0400, Jeff Dike wrote: > 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 > |
From: Peter T. <htm...@gm...> - 2008-07-22 08:45:44
|
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 :-). On Mon, Jul 21, 2008 at 11:46 PM, Jeff Dike <jd...@ad...> wrote: > 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 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 > -- Regards, Peter Teoh |
From: Jeff D. <jd...@ad...> - 2008-07-23 16:14:58
|
On Tue, Jul 22, 2008 at 11:27:13AM +0300, Boaz Harrosh wrote: > 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. > 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. > 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 -- Work email - jdike at linux dot intel dot com |