porting driver to 2.6, still unknown relocs... :(

Hi again.

As I described before, I try to port an audio driver from 2.4.x to 2.6.x.

It compiles, but on load I get "module snd_echoaudio: Unknown relocation: 0" from dmesg.

I looked into arch/*/kernel/module.c, and this error appears if the loaded module contains a relocation other than R_386_32 or R_386_PC32 (for intel).

Now I wonder, what would be an relocation type 0? The printk should also print the type in clear text I think, but it just prints 0. 0 also does not look very much like a valid value at all, or does it?

These are the commands used to build the modules (taken from the .*.cmd files):

// for the main module file:
gcc -Wp,-MD,sound/pci/echoaudio/.echoaudio.o.d -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon -Iinclude/asm-i386/mach-default -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon -Iinclude/asm-i386/mach-default -nostdinc -iwithprefix include -DMODULE -I/usr/include -Isound/pci/echoaudio/DSP -Isound/pci/echoaudio/ASIC -DGINA_20 -DECHO_LINUX -DECHOGALS_FAMILY -DKBUILD_BASENAME=echoaudio -DKBUILD_MODNAME=snd_echoaudio -c -o sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/echoaudio.c

// for the c++ helper files:
g++ -fno-rtti -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=athlon -Iinclude/asm-i386/mach-default -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -nostdinc -iwithprefix include -DMODULE -Isound/pci/echoaudio/DSP -Isound/pci/echoaudio/ASIC -DGINA_20 -DECHO_LINUX -DECHOGALS_FAMILY -DKBUILD_BASENAME=echoaudio -DKBUILD_MODNAME=snd_echoaudio -I/usr/include -o [email protected] [email protected]

// linking echoaudio.o
ld -m elf_i386 -r -o sound/pci/echoaudio/snd-echoaudio.o sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/OsSupportLinux.o sound/pci/echoaudio/CDaffyDuck.o sound/pci/echoaudio/CEchoGals_info.o
sound/pci/echoaudio/CEchoGals_transport.o sound/pci/echoaudio/CPipeOutCtrl.o sound/pci/echoaudio/CEchoGals_mixer.o sound/pci/echoaudio/CMidiInQ.o sound/pci/echoaudio/CEchoGals_midi.o sound/pci/echoaudio/CEchoGals_power.o sound/pci/echoaudio/CEchoGals.o sound/pci/echoaudio/CLineLevel.o sound/pci/echoaudio/CMonitorCtrlL.o sound/pci/echoaudio/CChannelMask.o sound/pci/echoaudio/CGdDspCommObject.o sound/pci/echoaudio/CDspCommObject.o sound/pci/echoaudio/CGinaDspCommObject.o sound/pci/echoaudio/CGina.o

// linking snd-echoaudio.o
ld -m elf_i386 -r -o sound/pci/echoaudio/snd-echoaudio.o sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/OsSupportLinux.o sound/pci/echoaudio/CDaffyDuck.o sound/pci/echoaudio/CEchoGals_info.o
sound/pci/echoaudio/CEchoGals_transport.o sound/pci/echoaudio/CPipeOutCtrl.o sound/pci/echoaudio/CEchoGals_mixer.o sound/pci/echoaudio/CMidiInQ.o sound/pci/echoaudio/CEchoGals_midi.o sound/pci/echoaudio/CEchoGals_power.o sound/pci/echoaudio/CEchoGals.o sound/pci/echoaudio/CLineLevel.o sound/pci/echoaudio/CMonitorCtrlL.o sound/pci/echoaudio/CChannelMask.o sound/pci/echoaudio/CGdDspCommObject.o sound/pci/echoaudio/CDspCommObject.o sound/pci/echoaudio/CGinaDspCommObject.o sound/pci/echoaudio/CGina.o

// linking snd-echoaudio.ko
ld -m elf_i386 -r -o sound/pci/echoaudio/snd-echoaudio.ko sound/pci/echoaudio/snd-echoaudio.o sound/pci/echoaudio/snd-echoaudio.mod.o

I have no idea why those commands should lead to a file with broken relocations. Please help me...

thanks,
Lars

On Wed, 27 Aug 2003 15:38:26 +0200 LGW <[email protected]> wrote:

| Hi again.
| 
| As I described before, I try to port an audio driver from 2.4.x to 2.6.x.
| 
| It compiles, but on load I get "module snd_echoaudio: Unknown 
| relocation: 0" from dmesg.
| 
| I looked into arch/*/kernel/module.c, and this error appears if the 
| loaded module contains a relocation other than R_386_32 or R_386_PC32 
| (for intel).
| 
| Now I wonder, what would be an relocation type 0? The printk should also 
| print the type in clear text I think, but it just prints 0. 0 also does 
| not look very much like a valid value at all, or does it?

Maybe g++ generates something different?
Are parts of your driver in c++?

| These are the commands used to build the modules (taken from the .*.cmd 
| files):
| 
| // for the main module file:
| gcc -Wp,-MD,sound/pci/echoaudio/.echoaudio.o.d -Wall -Wstrict-prototypes 
| -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe 
| -mpreferred-stack-boundary=2 -march=athlon 
| -Iinclude/asm-i386/mach-default -D__KERNEL__ -Iinclude  -Wall 
| -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
| -pipe -mpreferred-stack-boundary=2 -march=athlon 
| -Iinclude/asm-i386/mach-default -nostdinc -iwithprefix include -DMODULE 
| -I/usr/include -Isound/pci/echoaudio/DSP -Isound/pci/echoaudio/ASIC 
| -DGINA_20 -DECHO_LINUX -DECHOGALS_FAMILY  -DKBUILD_BASENAME=echoaudio 
| -DKBUILD_MODNAME=snd_echoaudio -c
| -o sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/echoaudio.c
| 
| // for the c++ helper files:
| g++ -fno-rtti -Wall -Wstrict-prototypes -Wno-trigraphs -O2 
| -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=athlon 
| -Iinclude/asm-i386/mach-default -D__KERNEL__ -Iinclude  -Wall 
| -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -nostdinc 
| -iwithprefix include -DMODULE -Isound/pci/echoaudio/DSP 
| -Isound/pci/echoaudio/ASIC -DGINA_20 -DECHO_LINUX -DECHOGALS_FAMILY  
| -DKBUILD_BASENAME=echoaudio -DKBUILD_MODNAME=snd_echoaudio 
| -I/usr/include -o [email protected] [email protected]
| 
| // linking echoaudio.o
| ld -m elf_i386  -r -o sound/pci/echoaudio/snd-echoaudio.o 
| sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/OsSupportLinux.o 
| sound/pci/echoaudio/CDaffyDuck.o sound/pci/echoaudio/CEchoGals_info.o
| sound/pci/echoaudio/CEchoGals_transport.o 
| sound/pci/echoaudio/CPipeOutCtrl.o sound/pci/echoaudio/CEchoGals_mixer.o 
| sound/pci/echoaudio/CMidiInQ.o sound/pci/echoaudio/CEchoGals_midi.o 
| sound/pci/echoaudio/CEchoGals_power.o sound/pci/echoaudio/CEchoGals.o 
| sound/pci/echoaudio/CLineLevel.o sound/pci/echoaudio/CMonitorCtrlL.o 
| sound/pci/echoaudio/CChannelMask.o 
| sound/pci/echoaudio/CGdDspCommObject.o 
| sound/pci/echoaudio/CDspCommObject.o 
| sound/pci/echoaudio/CGinaDspCommObject.o sound/pci/echoaudio/CGina.o
| 
| // linking snd-echoaudio.o
| ld -m elf_i386  -r -o sound/pci/echoaudio/snd-echoaudio.o 
| sound/pci/echoaudio/echoaudio.o sound/pci/echoaudio/OsSupportLinux.o 
| sound/pci/echoaudio/CDaffyDuck.o sound/pci/echoaudio/CEchoGals_info.o
| sound/pci/echoaudio/CEchoGals_transport.o 
| sound/pci/echoaudio/CPipeOutCtrl.o sound/pci/echoaudio/CEchoGals_mixer.o 
| sound/pci/echoaudio/CMidiInQ.o sound/pci/echoaudio/CEchoGals_midi.o 
| sound/pci/echoaudio/CEchoGals_power.o sound/pci/echoaudio/CEchoGals.o 
| sound/pci/echoaudio/CLineLevel.o sound/pci/echoaudio/CMonitorCtrlL.o 
| sound/pci/echoaudio/CChannelMask.o 
| sound/pci/echoaudio/CGdDspCommObject.o 
| sound/pci/echoaudio/CDspCommObject.o 
| sound/pci/echoaudio/CGinaDspCommObject.o sound/pci/echoaudio/CGina.o
| 
| // linking snd-echoaudio.ko
| ld -m elf_i386 -r -o sound/pci/echoaudio/snd-echoaudio.ko 
| sound/pci/echoaudio/snd-echoaudio.o sound/pci/echoaudio/snd-echoaudio.mod.o
| 
| I have no idea why those commands should lead to a file with broken 
| relocations. Please help me...

--
~Randy

I think the g++ is the problem, but I'm not sure what it is.

The driver is mostly a wrapper around a generic driver released by the manufacturer, and that's written in C++. But it worked like this for the 2.4.x kernel series, so I think it has something todo with the new module loader code. Possibly ld misses something when linking the object specific stuff like constructors?

I don't think there are any other errors in the module (like incompatible MODULE_stuff or missing statements), as it has been copied from a patched alsa-0.9.6, and I diff'd the other drivers, not finding much differences (if any).

Any ld parameters I could try? I already tried -Ur, but that lead to nothing :(

thanks,
Lars

On Wed, 27 Aug 2003 17:34:29 +0200 LGW <[email protected]> wrote:

| Randy.Dunlap wrote:
| 
| >On Wed, 27 Aug 2003 15:38:26 +0200 LGW <[email protected]> wrote:
| >
| >| Now I wonder, what would be an relocation type 0? The printk should also 
| >| print the type in clear text I think, but it just prints 0. 0 also does 
| >| not look very much like a valid value at all, or does it?

In 2.6.0, include/asm-i386/elf.h lists the ELF relocation types. Type 0 is "R_386_NONE". Apparently something is being generated with "no relocation needed" if I interpret this correctly (?).

| >Maybe g++ generates something different?
| >Are parts of your driver in c++?
| >
| I think the g++ is the problem, but I'm not sure what it is.
| 
| The driver is mostly a wrapper around a generic driver released by the 
| manufacturer, and that's written in C++. But it worked like this for the 
| 2.4.x kernel series, so I think it has something todo with the new 
| module loader code. Possibly ld misses something when linking the object 
| specific stuff like constructors?

Maybe. It probably wasn't meant to support C++.

Is the generic driver source code available?

| I don't think there are any other errors in the module (like 
| incompatible MODULE_stuff or missing statements), as it has been copied 
| from a patched alsa-0.9.6, and I diff'd the other drivers, not finding 
| much differences (if any).
| 
| Any ld parameters I could try? I already tried -Ur, but that lead to 
| nothing :(

--
~Randy

The new module loader is kernel side, it may well not know some of the C++ specific relocation types.

To you think it's possible to remove those relocations completely, so that the whole C++ stuff is linked "without" any more open relocations?

After all, those are only "helper functions" that could be linked "statically", or am I mistaken?

I don't have such deep knowledge of the C++ linking process, so I can't answer that question myself.

The Generic Driver is not public available I think, but you could get it here:
http://space.virgilio.it/[email protected]/ea.html (site with the patches for alsa)
http://space.virgilio.it/[email protected]/eagd-0.6.0.tar.bz2 (the original generic driver code)

thanks,
Lars

On Wed, 27 Aug 2003 18:15:51 +0200 LGW <[email protected]> wrote:

| Alan Cox wrote:
| 
| >On Mer, 2003-08-27 at 16:34, LGW wrote:
| >  
| >
| >>The driver is mostly a wrapper around a generic driver released by the 
| >>manufacturer, and that's written in C++. But it worked like this for the 
| >>2.4.x kernel series, so I think it has something todo with the new 
| >>module loader code. Possibly ld misses something when linking the object 
| >>specific stuff like constructors?
| >>    
| >>
| >
| >The new module loader is kernel side, it may well not know some of the
| >C++ specific relocation types. 
| >
| To you think it's possible to remove those relocations completely, so 
| that the whole C++ stuff is linked "without" any more open relocations?

Hopefully Rusty will see this and make some comments on it.

You could try using objdump to look for the item(s) that have this relocation type (0). That might help to see what is causing it.

Or you could modify the module loader to ignore relocation type 0... and see what happens.

| After all, those are only "helper functions" that could be linked 
| "statically", or am I mistaken?
| 
| I don't have such deep knowledge of the C++ linking process, so I can't 
| answer that question myself.
| 
| The Generic Driver is not public available I think, but you could get it 
| here:
| http://space.virgilio.it/[email protected]/ea.html (site with the 
| patches for alsa)
| http://space.virgilio.it/[email protected]/eagd-0.6.0.tar.bz2 (the 
| original generic driver code)

--
~Randy

Hm objdump -r snd-echoaudio.ko gives about six records (of course many others):
R_386_NONE *ABS*

I'm not really sure what they refer to. Or, I don't even know. I think that the driver uses some system functions and they are linked like that, or so? I had a look and R_386_NONE means "no relocation" - so it should be safe to ignore them?

Modifying the kernel module loader like

switch (reloc_type) {
...
case R_386_NONE:
break;
...
}

did the trick, but this feels like a really really really UGLY trick.

Of course the best thing would be to rewrite the whole stuff, as it is more than hacked together, but I don't have time to do so, know. At least the soundcard device appears and plays sound now. I'll see what time brings.

Thanks for your support,
Lars

You did something that was explicitly not supported on 2.4 and it worked, it broke on 2.6.

The fact that it worked it all on 2.4 was a fluke.

It's time to breakdown, do the right thing and figure out how to rewrite/translate the C++ code to C.

                             ^^^^^^^^^^^^^^^^^^^^^^^^_______ Yes!

There was lots of discussion/flames back-and-forth with newbies requiring that modules be written in C++. This is what you get. Some of the C++ built-ins are not even global so the linker won't be able to find them if they are used. It's not just a matter of emulating 'new'. Parameter-passing 'by reference' also won't work so putting 'C' wrappers around stuff like they do in Dr. Jobbs and C/C++ Journal isn't going to work inside the kernel where there is no support.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (794.73 BogoMips).
Note 96.31% of all statistics are fiction.

I absolutly agree with your opinion here. But due to the fact that the driver sources from the manufacturer where c++, a wrapper was easier (and the license of the driver is... restrictive I'm afraid...). But a rewrite in C is only a matter of time!

anyway, I have sound again, that's enough for the next few weeks I think.

regards,
Lars