Bug in module loading system on x86-64?

[Kendall Bennett]

Stuart Anderson <anderson at netsweng.com> wrote:

> > Now normally this should not be a problem, but it caused major issues
> > with the module loader, specifically when resolving symbols. When we
> > tried to load either the DDC module or later the framebuffer module when
> > we disabled the DDC module, none of the symbols were resolved correctly
> > and as soon as tried to call any of the functions within the module the X
> > server crashed (the pointers were basically bogus).
> 
> Were some of these relocation 32 bit? 

I assume the modules were built as ELF64 modules, so they shouldn't have 
32-bit relocatiosn in them, would they? I don't think our module loader 
(which uses ELF64 on that platform) had problems with 32-bit relocations, 
but then again I am not sure we loaded any of our private modules after 
the bad memory allocation. I will test that though to see if our loader 
is affected also.

> Once memory starts getting allocated from beyond 4G, 32 bit
> relocation just aren't big enough. I saw something like this a
> long time ago on a PPC, which has a 24 bit offset jump instruction,
> but the modules were being loaded more than 24 bits apart. This was
> fixed by creating a small code stub to jump into, which then did a
> full 32 bit jump to the destination. I bet something similar could
> be done here if in fact this turns out to be the problem. 

Right, that could be part of the problem. Although it looked like the 
symbol itself was not resolved properly (but I am not familiar with how 
symbols are resolved with the X loaders).

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~