Problems porting L4Linux 2.4 module to 2.6

[Adam Lackorzynski]

On Wed Sep 21, 2005 at 11:55:04 +0200, Derick Swanepoel wrote:
> On 20/09/05, Adam Lackorzynski <adam at os.inf.tu-dresden.de> wrote:
> > In 2.6 they're writing the EXPORT_SYMBOLS directly under the functions
> > and not in a single file anymore. I've added a few to the bottom of the
> > main.c file but for sure not all the needed ones. We haven't been
> > playing around with l4 related modules lately so this is why those
> > symbols are missing. Just add the ones you need and send the list over,
> > I'll add them.
> 
> Thanks Adam. I added the following to arch/l4/kernel/main.c:
> 
> EXPORT_SYMBOL(kmalloc);
> EXPORT_SYMBOL(l4_sleep);
> EXPORT_SYMBOL(l4lx_thread_create);
> EXPORT_SYMBOL(l4lx_thread_shutdown);
> EXPORT_SYMBOL(l4rm_detach);
> EXPORT_SYMBOL(l4rm_do_attach);
> 
> #include <l4/names/libnames.h>
> EXPORT_SYMBOL(names_waitfor_name);
> 
> I also needed l4env_err_ipcstrings, but it isn't defined anywhere so I
> added it as a dummy function to my module (as in
> pkg/overlay_wm/examples/xf86screen/dummy.c). I hope this is correct.

I've added those except kmalloc. How does it come that there's a kmalloc
symbol? kmalloc is a static inline function in slab.h so there should
not be an unresolved symbol, no?

> > > Secondly, I get more unresolved symbols if the objects that are linked
> > > are specified at the end of the command line instead of the beginning
> > > (linking succeeds in both cases, however). The kernel build system
> > > puts the objects at the end while the DROPS build system puts them at
> > > the beginning. Does anyone have an idea why two otherwise equivalent
> > > linking commands would cause such different behaviour depending on the
> > > position of the object arguments? Here are the two command lines (the
> > > paths are slightly different because the kernel build system always
> > > outputs to the source directory:
> > 
> > I guess that's because of the way ld works, it only processes the list
> > of arguments once (if not told otherwise) and depending on the order of
> > the objects/libs given different unresolved symbols may occur.
> 
> I know that one can tell ld to repeatedly search archives until no new
> undefined symbols are created (using --start-group and --end-group),
> but this didn't help. Is there another way? For now I've resorted to
> hacking the kernel build system to place the objects at the beginning,
> but I know this is not the right way.

Well but it works nevertheless? Generally I'd recommend to use the Linux
build system to build modules, should be easy with the "make -C ...
M=..." syntax.



Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/