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
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?
>
>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?
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
>| // 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
>
>
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
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.
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?
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
On 27 Aug 2003 16:59:38 +0100
Alan Cox <[email protected]> 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.
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.
Randy.Dunlap wrote:
>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.
>
>
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
On Wed, 27 Aug 2003, Stephen Hemminger wrote:
> On 27 Aug 2003 16:59:38 +0100
> Alan Cox <[email protected]> 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.
>
> 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.
>
> You did something that was explicitly not supported on 2.4 and it worked,
^^^^^^^^^^^^^^^^^^^^^^^^_______ 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.
Richard B. Johnson wrote:
>On Wed, 27 Aug 2003, Stephen Hemminger wrote:
>
>
>
>>On 27 Aug 2003 16:59:38 +0100
>>Alan Cox <[email protected]> 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.
>>>
>>>
>>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.
>>
>>
>>
>
>
>
>>You did something that was explicitly not supported on 2.4 and it worked,
>>
>>
> ^^^^^^^^^^^^^^^^^^^^^^^^_______ 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.
>
>
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