[Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Marc Aurele La France]

On Wed, 9 Aug 2000, Michael Madore wrote:

> 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"

> vgaHWddc1SetSpeed is defined in /usr/X11R6/lib/modules/libvgahw.so

> 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.

Marc.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310           |
|  Computing and Network Services  |  fax:    1-780-492-1729           |
|  352 General Services Building   |  email:  tsi@ualberta.ca          |
|  University of Alberta           +-----------------------------------+
|  Edmonton, Alberta               |                                   |
|  T6G 2H1                         |     Standard disclaimers apply    |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 Core Team member.  ATI driver and X server internals.

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Bill Nottingham]

Marc Aurele La France (tsi@gpu.srv.ualberta.ca) said: 
> > (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
> 
> > How 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).

> 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

[Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Michael Madore]

Hi,

> > (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
> 
> > 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.

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Michael Madore]

Hi,

> > 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

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Marc Aurele La France]

On Wed, 9 Aug 2000, Michael Madore wrote:

> > > 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:  tsi@ualberta.ca          |
|  University of Alberta           +-----------------------------------+
|  Edmonton, Alberta               |                                   |
|  T6G 2H1                         |     Standard disclaimers apply    |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 Core Team member.  ATI driver and X server internals.

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Bill Nottingham]

Marc Aurele La France (tsi@gpu.srv.ualberta.ca) said: 
> > > 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

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Stuart Anderson]

On Thu, 10 Aug 2000, Michael Madore wrote:

> 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                               anderson@metrolink.com

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
http://www.metrolink.com/

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Michael Madore]

Hi,

On Thu, 10 Aug 2000, Bill Nottingham wrote:

> Marc Aurele La France (tsi@gpu.srv.ualberta.ca) said: 
> > > > 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.

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Bill Nottingham]

Stuart Anderson (anderson@metrolink.com) said: 
> > 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 (jakub@redhat.com) is
the one who did the actual patch.

Bill

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Stuart Anderson]

On Thu, 10 Aug 2000, Bill Nottingham wrote:

> 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.

> If the X people want me to post what we have, I can do that;

That would be good.

> it's obviously hard to debug the module loader without the
> actual hardware. :)

Hardware does make it easier 8-)


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

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
http://www.metrolink.com/

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Keith Owens]

On Thu, 10 Aug 2000 12:54:16 -0400 (EDT), 
Stuart Anderson <anderson@metrolink.com> wrote:
>On Thu, 10 Aug 2000, Michael Madore wrote:
>> 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.

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[David Dawes]

On Thu, Aug 10, 2000 at 10:00:20AM -0700, Michael Madore wrote:
>Hi,
>
>On Thu, 10 Aug 2000, Bill Nottingham wrote:
>
>> Marc Aurele La France (tsi@gpu.srv.ualberta.ca) said: 
>> > > > 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?

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

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Marc Aurele La France]

On Fri, 11 Aug 2000, Keith Owens wrote:

> >> 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.

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:  tsi@ualberta.ca          |
|  University of Alberta           +-----------------------------------+
|  Edmonton, Alberta               |                                   |
|  T6G 2H1                         |     Standard disclaimers apply    |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 Core Team member.  ATI driver and X server internals.

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Michael Madore]

Hi Marc,

On Wed, 16 Aug 2000, Marc Aurele La France wrote:

> On Fri, 11 Aug 2000, Keith Owens wrote:
> 
> > >> 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.
> 
> 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

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Stuart Anderson]

I've received some code, and should have hardware soon, so I was planning
on working on it.


On Wed, 16 Aug 2000, Marc Aurele La France wrote:

> On Fri, 11 Aug 2000, Keith Owens wrote:
> 
> > >> 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.
> 
> 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:  tsi@ualberta.ca          |
> |  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                               anderson@metrolink.com

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
http://www.metrolink.com/

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Hiram Clawson, 831-427-7519]

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 <anderson@metrolink.com>
 To: Marc Aurele La France <tsi@gpu.srv.ualberta.ca>
 cc: Keith Owens <kaos@ocs.com.au>, Michael Madore <mmadore@turbolinux.com>, 
     Bill Nottingham <notting@redhat.com>, linux-ia64@linuxia64.org
 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.
 
 On Wed, 16 Aug 2000, Marc Aurele La France wrote:
 
 > On Fri, 11 Aug 2000, Keith Owens wrote:
 > 
 > > >> 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.
 > 
 > 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           |

Re: [Linux-ia64] Re: [Xpert] XFree 4.0.1 module loading

[Marc Aurele La France]

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:

> 	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.

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:  tsi@ualberta.ca          |
|  University of Alberta           +-----------------------------------+
|  Edmonton, Alberta               |                                   |
|  T6G 2H1                         |     Standard disclaimers apply    |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 Core Team member.  ATI driver and X server internals.