XFree 4.0.1 module loading
Quoted 17 lines · Michael Madore
I have XFree 4.0.1 built on IA64, however I am having an issue with loadable modules that I would like to address.
Loading individual modules works fine. Unfortunately, if a module references a symbol inside another module, the
dlopen()call won't resolve the symbol.This is primarily a problem while running XFree86 -configure to create an initial configure file. Here is an example:
(II) LoadModule: "mga"
(II) Loading/usr/X11R6/lib/modules/drivers/mga_drv.so
dlopen:/usr/X11R6/lib/modules/drivers/mga_drv.so: undefined symbol:
vgaHWddc1SetSpeed
(EE) Failed to load/usr/X11R6/lib/modules/drivers/mga_drv.so(II) UnloadModule: "mga"
Quoted 3 lines
vgaHWddc1SetSpeed is defined in
/usr/X11R6/lib/modules/libvgahw.soHow would
dlopen()know to look at that module to resolve the dependency?
Looks like you built the server and modules with MakeDllModules #define'd to YES. This should work without it, i.e. leaving MakeDllModules to the default of NO. Some dlopen() implementations require all symbols to be resolved after each module no matter what you tell it in the call. This seems to me to be the problem here.
Marc.
+----------------------------------+-----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax: 1-780-492-1729 | | 352 General Services Building | email: [email protected] | | University of Alberta +-----------------------------------+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply | | CANADA | | +----------------------------------+-----------------------------------+ XFree86 Core Team member. ATI driver and X server internals.
Quoted 10 lines · Marc Aurele La France
Quoted 10 lines
(II) LoadModule: "mga"
(II) Loading/usr/X11R6/lib/modules/drivers/mga_drv.so
dlopen:/usr/X11R6/lib/modules/drivers/mga_drv.so: undefined symbol:
vgaHWddc1SetSpeed
(EE) Failed to load/usr/X11R6/lib/modules/drivers/mga_drv.so(II) UnloadModule: "mga"vgaHWddc1SetSpeed is defined in
/usr/X11R6/lib/modules/libvgahw.soHow would
dlopen()know to look at that module to resolve the dependency?
You could link all the modules against their dependencies and futz with the library search path in the server. But that's pretty ugly, and you'd probably still run into problems with codependent modules (glx/GLcore).
Quoted 5 lines
Looks like you built the server and modules with MakeDllModules #define'd to YES. This should work without it, i.e. leaving MakeDllModules to the default of NO. Some
dlopen()implementations require all symbols to be resolved after each module no matter what you tell it in the call. This seems to me to be the problem here.
Someone fixed the elfloader on ia64? Last I checked it doesn't even *build* without patches, but I haven't tried it too recently.
Bill
Hi,
Quoted 9 lines
Quoted 8 lines
(II) LoadModule: "mga"
(II) Loading/usr/X11R6/lib/modules/drivers/mga_drv.so
dlopen:/usr/X11R6/lib/modules/drivers/mga_drv.so: undefined symbol:
vgaHWddc1SetSpeed
(EE) Failed to load/usr/X11R6/lib/modules/drivers/mga_drv.so(II) UnloadModule: "mga"vgaHWddc1SetSpeed is defined in
/usr/X11R6/lib/modules/libvgahw.so
Quoted 7 lines
Quoted 1 line
How would
dlopen()know to look at that module to resolve the dependency?Looks like you built the server and modules with MakeDllModules #define'd to YES. This should work without it, i.e. leaving MakeDllModules to the default of NO. Some
dlopen()implementations require all symbols to be resolved after each module no matter what you tell it in the call. This seems to me to be the problem here.
Yes, MakeDllModules was set to YES. I did notice that on IA32 the modules all ended in .a instead of .so. I assume that is because of this setting.
I based my build off of a SPEC file for XFree 4.0 which had this set to YES. I'll try it set to no and see if it works.
Thanks
Mike Madore
Software Engineer
TurboLinux, Inc.
Hi,
Quoted 8 lines
Quoted 5 lines
Looks like you built the server and modules with MakeDllModules #define'd to YES. This should work without it, i.e. leaving MakeDllModules to the default of NO. Some
dlopen()implementations require all symbols to be resolved after each module no matter what you tell it in the call. This seems to me to be the problem here.Someone fixed the elfloader on ia64? Last I checked it doesn't even *build* without patches, but I haven't tried it too recently.
I'm building with a patched version of the elfloader.
Mike Madore
Quoted 10 lines · Michael Madore
Quoted 8 lines
Quoted 5 lines
Looks like you built the server and modules with MakeDllModules #define'd to YES. This should work without it, i.e. leaving MakeDllModules to the default of NO. Some
dlopen()implementations require all symbols to be resolved after each module no matter what you tell it in the call. This seems to me to be the problem here.Someone fixed the elfloader on ia64? Last I checked it doesn't even *build* without patches, but I haven't tried it too recently.
I'm building with a patched version of the elfloader.
Is this patch available for integration into the base source?
Marc.
+----------------------------------+-----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax: 1-780-492-1729 | | 352 General Services Building | email: [email protected] | | University of Alberta +-----------------------------------+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply | | CANADA | | +----------------------------------+-----------------------------------+ XFree86 Core Team member. ATI driver and X server internals.
Quoted 6 lines · Marc Aurele La France
Quoted 4 lines
Quoted 2 lines
Someone fixed the elfloader on ia64? Last I checked it doesn't even *build* without patches, but I haven't tried it too recently.
I'm building with a patched version of the elfloader.
Is this patch available for integration into the base source?
I'm not sure about his patch, but the patch we have only allows it to build; it still doesn't work (we just use the dlopen() loader). That's why we never submitted it. :)
Bill
Quoted 3 lines · Michael Madore
I guess my question now is: Should the
dlopen()loader be able to resolve inter-module dependencies? If not, what is left to be done with the elf loader make it functional on IA64?
Support for the ELF64 relocation types. Just like a block of code was added for Alpha support, the same type of thing will have to be added for IA64.
Stuart
Stuart R. Anderson [email protected]
Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 fax: 954.938.1982 SkyTel: 800.405.3401
Hi,
Quoted 11 lines · Bill Nottingham
Quoted 6 lines · Marc Aurele La France
Quoted 4 lines
Quoted 2 lines
Someone fixed the elfloader on ia64? Last I checked it doesn't even *build* without patches, but I haven't tried it too recently.
I'm building with a patched version of the elfloader.
Is this patch available for integration into the base source?
I'm not sure about his patch, but the patch we have only allows it to build; it still doesn't work (we just use the
dlopen()loader). That's why we never submitted it. :)
I think that my patch IS your patch. ;-) It's from the XFree 4.0 shipped with the Red Hat IA64 distro.
So if I understand you correctly, applying that patch doesn't actually effect XFree86 beyond getting it to compile. In other words, the dlopen() method is independent of the patch?
I guess my question now is: Should the dlopen() loader be able to resolve inter-module dependencies? If not, what is left to be done with the elf loader make it functional on IA64?
Mike Madore
Software Engineer
TurboLinux, Inc.
Quoted 6 lines · Stuart Anderson
Quoted 3 lines
I guess my question now is: Should the
dlopen()loader be able to resolve inter-module dependencies? If not, what is left to be done with the elf loader make it functional on IA64?Support for the ELF64 relocation types. Just like a block of code was added for Alpha support, the same type of thing will have to be added for IA64.
Exactly; the patch we have does that, it just doesn't quite work yet. They way the loader is (please, correct me if I'm wrong) is that it can load modules in various ways: there's an a.out module loader, a dlopen() based loader, and an 'elfloader' that does all the elf relocations/symbol resolution itself.
We compile the modules for use with the dlopen() based loader here because that works for us, and we haven't worried about the inter-module dependencies that Michael is having yet. The elfloader patch we have is in a state where it compiles, does the relocations, etc., but it doesn't quite work (at least in testing here; other people may want to check if it works for them.) Since we were happy with how the dlopen() based stuff worked for us, we haven't worked on fixing the elfloader recently.
If the X people want me to post what we have, I can do that; it's obviously hard to debug the module loader without the actual hardware. :) Jakub Jelinek ([email protected]) is the one who did the actual patch.
Bill
Quoted 5 lines · Bill Nottingham
Exactly; the patch we have does that, it just doesn't quite work yet. They way the loader is (please, correct me if I'm wrong) is that it can load modules in various ways: there's an a.out module loader, a
dlopen()based loader, and an 'elfloader' that does all the elf relocations/symbol resolution itself.
Correct. You can even mix & match between ELF, a.out & COFF on architectures that support multiple formats. The dlopen() loader does it's bookkeeping seperately, so you can't mix and match it with the other formats.
Quoted 1 line
If the X people want me to post what we have, I can do that;
That would be good.
Quoted 2 lines
it's obviously hard to debug the module loader without the actual hardware. :)
Hardware does make it easier 8-)
Stuart
Stuart R. Anderson [email protected]
Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 fax: 954.938.1982 SkyTel: 800.405.3401
Quoted 7 lines · Stuart Anderson
Quoted 3 lines · Michael Madore
I guess my question now is: Should the
dlopen()loader be able to resolve inter-module dependencies? If not, what is left to be done with the elf loader make it functional on IA64?Support for the ELF64 relocation types. Just like a block of code was added for Alpha support, the same type of thing will have to be added for IA64.
modutils 2.3.13 has IA64 relocation support, courtesy of Mike Stephens at Intel. obj/obj_ia64.c should be a reasonable starting point.
Quoted 19 lines · Michael Madore
Hi,
Quoted 11 lines · Bill Nottingham
Quoted 6 lines · Marc Aurele La France
Quoted 4 lines
Quoted 2 lines
Someone fixed the elfloader on ia64? Last I checked it doesn't even *build* without patches, but I haven't tried it too recently.
I'm building with a patched version of the elfloader.
Is this patch available for integration into the base source?
I'm not sure about his patch, but the patch we have only allows it to build; it still doesn't work (we just use the
dlopen()loader). That's why we never submitted it. :)I think that my patch IS your patch. ;-) It's from the XFree 4.0 shipped with the Red Hat IA64 distro.
Quoted 7 lines
So if I understand you correctly, applying that patch doesn't actually effect XFree86 beyond getting it to compile. In other words, the
dlopen()method is independent of the patch?I guess my question now is: Should the
dlopen()loader be able to resolve inter-module dependencies? If not, what is left to be done with the elf loader make it functional on IA64?
The dlopen() "loader" in XFree86 is mostly there for development purposes. One reason we don't use it routinely is the problem with inter-module dependencies. The best thing would be to get the elf loader working on IA64.
David
Quoted 9 lines · Keith Owens
Quoted 6 lines
Quoted 3 lines
I guess my question now is: Should the
dlopen()loader be able to resolve inter-module dependencies? If not, what is left to be done with the elf loader make it functional on IA64?Support for the ELF64 relocation types. Just like a block of code was added for Alpha support, the same type of thing will have to be added for IA64.
modutils 2.3.13 has IA64 relocation support, courtesy of Mike Stephens at Intel.
obj/obj_ia64.cshould be a reasonable starting point.
Is anyone going ahead with this? If not, I can probably come pretty close to getting it working even though I'd be going in blind (no hardware).
Let me know.
Marc.
+----------------------------------+-----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax: 1-780-492-1729 | | 352 General Services Building | email: [email protected] | | University of Alberta +-----------------------------------+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply | | CANADA | | +----------------------------------+-----------------------------------+ XFree86 Core Team member. ATI driver and X server internals.
Hi Marc,
Quoted 9 lines · Marc Aurele La France
Quoted 6 lines · Keith Owens
Quoted 6 lines
Quoted 3 lines
I guess my question now is: Should the
dlopen()loader be able to resolve inter-module dependencies? If not, what is left to be done with the elf loader make it functional on IA64?Support for the ELF64 relocation types. Just like a block of code was added for Alpha support, the same type of thing will have to be added for IA64.
Quoted 7 lines
Quoted 2 lines
modutils 2.3.13 has IA64 relocation support, courtesy of Mike Stephens at Intel.
obj/obj_ia64.cshould be a reasonable starting point.Is anyone going ahead with this? If not, I can probably come pretty close to getting it working even though I'd be going in blind (no hardware).
Let me know.
This is on my list of things to work on, but any help would certainly be welcome.
Mike Madore
I've received some code, and should have hardware soon, so I was planning on working on it.
Quoted 19 lines · Marc Aurele La France
Quoted 9 lines · Keith Owens
Quoted 6 lines
Quoted 3 lines
I guess my question now is: Should the
dlopen()loader be able to resolve inter-module dependencies? If not, what is left to be done with the elf loader make it functional on IA64?Support for the ELF64 relocation types. Just like a block of code was added for Alpha support, the same type of thing will have to be added for IA64.
modutils 2.3.13 has IA64 relocation support, courtesy of Mike Stephens at Intel.
obj/obj_ia64.cshould be a reasonable starting point.Is anyone going ahead with this? If not, I can probably come pretty close to getting it working even though I'd be going in blind (no hardware).
Let me know.
Marc.
Quoted 11 lines
+----------------------------------+-----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax: 1-780-492-1729 | | 352 General Services Building | email: [email protected] | | University of Alberta +-----------------------------------+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply | | CANADA | | +----------------------------------+-----------------------------------+ XFree86 Core Team member. ATI driver and X server internals.
Stuart
Stuart R. Anderson [email protected]
Metro Link Incorporated South Carolina Office 5807 North Andrews Way 129 Secret Cove Drive Fort Lauderdale, Florida 33309 Lexington, SC 29072 voice: 954.660.2500 voice: 803.951.3630 fax: 954.938.1982 SkyTel: 800.405.3401
Rather than trying to work with the XFree86 X server to fix up this loading situation, it is a lot easier to create a couple of tiny example programs that dlopen() each other to watch the interaction.
I believe you are talking about the sequence:
main() dlopens foo0()
foo0() and main() can freely exchange references with each other. Now foo0() dlopens foo1()
The question is, which of main(), foo0() and foo1() can freely exchange references with each other ? Which types of dynamic loading schemes will allow all loaded programs to share all symbols.
--Hiram
Date: Thu, 17 Aug 2000 12:13:33 -0400 (EDT)
From: Stuart Anderson <[email protected]>
To: Marc Aurele La France <[email protected]>
cc: Keith Owens <[email protected]>, Michael Madore <[email protected]>,
Bill Nottingham <[email protected]>, [email protected]
Subject: Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading
I've received some code, and should have hardware soon, so I was planning on working on it.
Quoted 7 lines · Marc Aurele La France
Quoted 5 lines · Keith Owens
Quoted 5 lines
Quoted 3 lines
I guess my question now is: Should the
dlopen()loader be able to resolve inter-module dependencies? If not, what is left to be done with the elf loader make it functional on IA64?Support for the ELF64 relocation types. Just like a block of code was
added
Quoted 14 lines
Quoted 4 lines
Quoted 1 line
for Alpha support, the same type of thing will have to be added for IA64.
modutils 2.3.13 has IA64 relocation support, courtesy of Mike Stephens at Intel.
obj/obj_ia64.cshould be a reasonable starting point.Is anyone going ahead with this? If not, I can probably come pretty close to getting it working even though I'd be going in blind (no hardware).
Let me know.
Marc.
+----------------------------------+-----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 |
Quoted 6 lines · On Thu, 17 Aug 2000, Hiram Clawson, 831-427-7519 wrote:
Rather than trying to work with the XFree86 X server to fix up this loading situation, it is a lot easier to create a couple of tiny example programs that
dlopen()each other to watch the interaction.I believe you are talking about the sequence:
Quoted 7 lines
main()dlopensfoo0()
foo0()andmain()can freely exchange references with each other. Nowfoo0()dlopensfoo1()
The question is, which ofmain(),foo0()andfoo1()can freely exchange references with each other ? Which types of dynamic loading schemes will allow all loaded programs to share all symbols.
No, there are actually two problems here. One is that, in practice, the use of dlopen() isn't portable because some implementations do not implement the LAZY flag properly, instead requiring all symbols to be defined after each dlopen().
The second issue is that there are circular references between certain XFree86 modules (although, to my knowledge, Michael has yet to run into them).
As used in XFree86, the dlopen loader is primarily meant to ease development on new platforms, and, in the end, a publically released server should not ship with dlopen modules. Metrolink likely had (has) other ideas about this, but that's basically how we've used it. Among other things, this policy allows us to support OS'es that don't provide dlopen(), in an OS-independent way.
The dlopen loader does have one advantage, however, that being that a module's symbols become undefined when the module is unloaded.
Marc.
+----------------------------------+-----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax: 1-780-492-1729 | | 352 General Services Building | email: [email protected] | | University of Alberta +-----------------------------------+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply | | CANADA | | +----------------------------------+-----------------------------------+ XFree86 Core Team member. ATI driver and X server internals.