Description of problem: The kernel in rawhide installer image for PowerPC fails in loading kernel modules because of the error 'Unknown ADD relocation: 26'. Version-Release number of selected component (if applicable): kernel-2.6.29-0.131.rc5.git2.fc11.ppc64 How reproducible: Every time. Steps to Reproduce: 1. Insert rawhide's boot disc (boot.iso) into target machine. (I tried on PLAYSTATION 3). 2. Choose language. 3. Choose keyboard type. 4. Choose installation method (I tried 'NFS directory'). Actual results: Unexpected 'No driver found' dialog is displayed. If switching to tty4 by ALT+F4, it shows kernel's error messages: <4>spufs: Unknown ADD relocation: 26 <4>ps3stor_lib: Unknown ADD relocation: 26 <4>ps3rom: Unknown ADD relocation: 26 <4>usb_stoage: Unknown ADD relocation: 26 etc... Expected results: The kernel modules are properly loaded. Additional info:
I tried upstream kernel 2.6.29-rc5-git7: * Built by gcc-4.4.0-0.20.ppc (rawhide): same error * Built by gcc-4.3.2-7.pcc (Fedora 10): OK So I guess: * gcc 4.4 generates relocation type R_PPC64_REL32 (== 26) for modules. * gcc 4.3 doesn't. * the current kernel doesn't support R_PPC64_REL32 (yet).
According to readelf -rSW "module", it looks like the .eh_frame section causes the problem. R_PPC64_REL32 relocations are generated only in .rela.eh_frame section, and only gcc 4.4 emits the .rela.eh_frame and .eh_frame.
I see similar (but less descriptive) errors loading modules with my G5 now that the prom_init.o gcc bug is fixed. http://jwboyer.fedorapeople.org/pub/IMG_3639.JPG
Hi, this isn't really my area, but looking at binutils and glibc's dl-machine files, it looks like this is just a simple pcrel fixup. I've started a testbuild here, no promises it doesn't accidently fixup the pc to point to panic() or explode some kittens or something. http://koji.fedoraproject.org/koji/taskinfo?taskID=1147224
gcc-4.4.0-0.21.ppc running under -m64 seems to default to emitting .eh_frame info. This is a change from 4.3/f10 and affects building kernel modules. We did not find a combination of -fno-asynchronous-unwind-tables et al that turned it off. Defaulting to on is OK if there is a consistent way to disable it that we can use in the kernel makefiles.
Does -fno-dwarf2-cfi-asm avoid the creation of this section? This is enabled by default if the assembler supports .cfi* directives and debug information is requested, and causes the assembler to emit .eh_frame sections, even if the compiler itself doesn't. If that doesn't fix it, would you please get me a simple preprocessed testcase and command line that triggers the creation of such a section, so that I can duplicate the problem without having to figure out how to get a kernel build to use a locally-built compiler. (I don't have easy access to ppc rawhide boxes). Thanks,
FTR, I've just finished building recent binutils and gcc on the ppc box I've got access to. I verified that compiling a trivial 'main(){}' program with -O2 -g creates an object file with a .eh_frame section, and that adding -fno-dwarf2-cfi-asm to the command line creates an object file without this section. I suggest the Linux build machinery to use this option when GCC offers it. I'm pretty sure there's support in the Linux build machinery to use options only when they're available.
Thanks Alexandre, I've cooked a patch and will CC you when I send it in. It'll go into the next release of the rawhide kernel as well. regards, Kyle
Hi, The patch should be in this kernel, http://koji.fedoraproject.org/koji/buildinfo?buildID=84761 Josh Boyer has confirmed it fixes things on his powerpc, could I ask that you give it a try as well? cheers, Kyle
I confirmed my problem was fixed in 2.6.29-0.147.rc6.fc11 on PS3. Thanks!
Patch went into 2.6.29 upstream too.