undefined functions and lazy dlopen()

[Manuel Bouyer]

Hello,
trying to get the sis xorg driver working on loonson, I hit an issue with
dlopen() and lazy bindings. Note that this is with n32 binaries, not o32
(this makes a difference in mips_reloc.c).
Loading the module, xorg complains:

[ 1566.115] (II) Loading /usr/X11R7/lib/modules/drivers/sis_drv.so
[ 1566.124] (EE) Failed to load /usr/X11R7/lib/modules/drivers/sis_drv.so: /usr/X11R7/lib/modules/drivers/sis_drv.so: Undefined symbol "VBESetDisplayStart" (symnum = 301)

it also commplains for the siliconmotion driver:

[ 1565.970] (II) Loading /usr/X11R7/lib/modules/drivers/siliconmotion_drv.so
[ 1565.975] (EE) Failed to load /usr/X11R7/lib/modules/drivers/siliconmotion_drv.so: /usr/X11R7/lib/modules/drivers/siliconmotion_drv.so: Undefined symbol "exaOffscreenFree" (symnum = 101)

both functions have a 0 address in their respective .so, unlinke other
undefined functions:
cuba# objdump -x /usr/X11R7/lib/modules/drivers/siliconmotion_drv.so | grep exa
0001b2b0 F *UND* 00000000 exaDriverFini
0001b310 F *UND* 00000000 exaDriverAlloc
0001b3d0 F *UND* 00000000 exaWaitSync
0001b480 F *UND* 00000000 exaOffscreenAlloc
0001b520 F *UND* 00000000 exaDriverInit
0001b710 F *UND* 00000000 exaGetPixmapPitch
0001b770 F *UND* 00000000 exaGetPixmapOffset
00000000 F *UND* 00000000 exaOffscreenFree
cuba# objdump -x /usr/X11R7/lib/modules/drivers/sis_drv.so.0 | grep VBE 0007b820 F *UND* 00000000 VBEGetVBEMode
0007b840 F *UND* 00000000 VBESaveRestore
00000000 *UND* 00000000 VBESetDisplayStart
0007bc00 F *UND* 00000000 VBEGetModeInfo
0007bdd0 F *UND* 00000000 VBEExtendedInit
0007be10 F *UND* 00000000 VBESetVBEMode
0007bec0 F *UND* 00000000 VBEFreeModeInfo
0007bff0 F *UND* 00000000 VBESetGetLogicalScanlineLength
0007c040 F *UND* 00000000 VBEFreeVBEInfo
0007c050 F *UND* 00000000 VBEGetVBEInfo

(also, VBESetDisplayStart is not marked F but I'm not sure it's an issue).

I think this is because these functions are R_MIPS_GOT_DISP and not
R_MIPS_CALL16:

/dsk/l1/misc/bouyer/tmp/evbmips64el/obj/netbsd-6/src/tooldir/bin/mips64el--netbsd-objdump -x sis_driver.o | grep VBE
000020e0 R_MIPS_CALL16 VBESaveRestore
00002118 R_MIPS_CALL16 VBESetVBEMode
00002140 R_MIPS_CALL16 VBEGetVBEMode
00002168 R_MIPS_CALL16 VBESaveRestore
0000222c R_MIPS_CALL16 VBESaveRestore
00002414 R_MIPS_CALL16 VBEExtendedInit
00010b30 R_MIPS_GOT_DISP VBESetDisplayStart
00011388 R_MIPS_CALL16 VBESetVBEMode
000113b4 R_MIPS_CALL16 VBESetGetLogicalScanlineLength
00013748 R_MIPS_CALL16 VBESetVBEMode
00013d38 R_MIPS_CALL16 VBESetVBEMode
00013f3c R_MIPS_CALL16 VBESetVBEMode
000144a4 R_MIPS_CALL16 VBEExtendedInit
0001a758 R_MIPS_CALL16 VBEGetVBEInfo
0001a7c8 R_MIPS_CALL16 VBEGetModeInfo
0001a80c R_MIPS_CALL16 VBEFreeModeInfo
0001be3c R_MIPS_CALL16 VBEFreeVBEInfo
0001becc R_MIPS_CALL16 VBEFreeModeInfo

houla:/dsk/l1/misc/bouyer/tmp/evbmips64el/obj/dsk/l1/misc/bouyer/netbsd-6/src/external/mit/xorg/server/drivers/xf86-video-sis>/dsk/l1/misc/bouyer/tmp/evbmips64el/obj/netbsd-6/src/tooldir/bin/mips64el--netbsd-objdump -x ../xf86-video-siliconmotion/smi_video.o | grep exa
00000000 *UND* 00000000 exaOffscreenFree
00000000 *UND* 00000000 exaOffscreenAlloc
00001d00 R_MIPS_CALL16 exaOffscreenFree
00001d18 R_MIPS_CALL16 exaOffscreenAlloc
00003470 R_MIPS_GOT_DISP exaOffscreenFree

Any idea ?

[Manuel Bouyer]

http://sourceware-org.1504.n7.nabble.com/MIPS-R-MIPS-GOT-DISP-interferes-with-lazy-binding-td230667.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57260
I will try to apply the patch here (or find the commit in the sources)
and see how it goes

I've built a (netbsd-6, as HEAD has issues) release and running it on
loongson, including kernel, with the attached patch. I didn't notice
side effects yet, and X can now load its modules (doens't work yet, but
now I can look at how to access registers :)

Any objection before I commit ?

[Manuel Bouyer]

Post by Manuel Bouyer
[...]
I think this is because these functions are R_MIPS_GOT_DISP and not

Looks similar to:
http://sourceware-org.1504.n7.nabble.com/MIPS-R-MIPS-GOT-DISP-interferes-with-lazy-binding-td230667.html

which triggered:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57260

I will try to apply the patch here (or find the commit in the sources)
and see how it goes

[Michael]

On Thu, 23 Jan 2014 15:55:05 +0100

Post by Manuel Bouyer
Hello,
trying to get the sis xorg driver working on loonson, I hit an issue with
dlopen() and lazy bindings. Note that this is with n32 binaries, not o32
(this makes a difference in mips_reloc.c).
[ 1566.115] (II) Loading /usr/X11R7/lib/modules/drivers/sis_drv.so
[ 1566.124] (EE) Failed to load /usr/X11R7/lib/modules/drivers/sis_drv.so: /usr/X11R7/lib/modules/drivers/sis_drv.so: Undefined symbol "VBESetDisplayStart" (symnum = 301)
[ 1565.970] (II) Loading /usr/X11R7/lib/modules/drivers/siliconmotion_drv.so
[ 1565.975] (EE) Failed to load /usr/X11R7/lib/modules/drivers/siliconmotion_drv.so: /usr/X11R7/lib/modules/drivers/siliconmotion_drv.so: Undefined symbol "exaOffscreenFree" (symnum = 101)

I've seen this too, got around it by telling xorg to unconditionally load the respective modules ( I think Load statements in the Server section did the trick ).

have fun
Michael

[Manuel Bouyer]

Post by Michael
I've seen this too, got around it by telling xorg to unconditionally load the respective modules ( I think Load statements in the Server section did the trick ).

Yes, that would work around the issue. But as I mentionned later, it
turns out it's a gcc bug which was fixed upstream, and for which I have
a patch.

[Michael]

On Fri, 24 Jan 2014 13:39:52 +0100

Post by Manuel Bouyer

Post by Michael
I've seen this too, got around it by telling xorg to unconditionally load the respective modules ( I think Load statements in the Server section did the trick ).

Yes, that would work around the issue. But as I mentionned later, it
turns out it's a gcc bug which was fixed upstream, and for which I have
a patch.

And I've been poking around in our dynamic linker, obviously without success,
I thought it's a problem in there since I've seen this bug only on Loongson, but not on sgimips.

have fun
Michael

[Manuel Bouyer]

Post by Michael
On Fri, 24 Jan 2014 13:39:52 +0100

Post by Manuel Bouyer

Post by Michael
I've seen this too, got around it by telling xorg to unconditionally load the respective modules ( I think Load statements in the Server section did the trick ).

Yes, that would work around the issue. But as I mentionned later, it
turns out it's a gcc bug which was fixed upstream, and for which I have
a patch.

And I've been poking around in our dynamic linker, obviously without success,
I thought it's a problem in there since I've seen this bug only on Loongson, but not on sgimips.

It's a bug affecting only N32/N64, but not O32.

[Michael]

Hello,

On Sat, 25 Jan 2014 13:14:14 +0100

Post by Manuel Bouyer

Post by Michael
On Fri, 24 Jan 2014 13:39:52 +0100

Post by Manuel Bouyer

Post by Michael
I've seen this too, got around it by telling xorg to unconditionally load the respective modules ( I think Load statements in the Server section did the trick ).

Yes, that would work around the issue. But as I mentionned later, it
turns out it's a gcc bug which was fixed upstream, and for which I have
a patch.

And I've been poking around in our dynamic linker, obviously without success,
I thought it's a problem in there since I've seen this bug only on Loongson, but not on sgimips.

It's a bug affecting only N32/N64, but not O32.

I meant N32 on sgimips. Before the latest messup it was almost usable, including X, but unfortunately not gcc.
Not exactly a supported configuration, my main reason for playing with it was that some CRIME registers can only really be used with 64bit accesses, which O32 would break down into 2x 32bit.

have fun
Michael

[Manuel Bouyer]

Post by Manuel Bouyer
Hello,
On Sat, 25 Jan 2014 13:14:14 +0100

Post by Manuel Bouyer

Post by Michael
On Fri, 24 Jan 2014 13:39:52 +0100

Post by Manuel Bouyer

Post by Michael
I've seen this too, got around it by telling xorg to unconditionally load the respective modules ( I think Load statements in the Server section did the trick ).

Yes, that would work around the issue. But as I mentionned later, it
turns out it's a gcc bug which was fixed upstream, and for which I have
a patch.

And I've been poking around in our dynamic linker, obviously without success,
I thought it's a problem in there since I've seen this bug only on Loongson, but not on sgimips.

It's a bug affecting only N32/N64, but not O32.

I meant N32 on sgimips. Before the latest messup it was almost usable, including X, but unfortunately not gcc.

So it's probably your were lucky :)
The bug affetcs only some symbols, in some specific cases.
That's why the loader doesn't complain about all lasy symbols but only one ...

[Michael]

Hello,

On Sat, 25 Jan 2014 15:29:05 +0100

Post by Manuel Bouyer

Post by Manuel Bouyer
Hello,
On Sat, 25 Jan 2014 13:14:14 +0100

Post by Manuel Bouyer

Post by Michael
On Fri, 24 Jan 2014 13:39:52 +0100

Post by Manuel Bouyer

Post by Michael
I've seen this too, got around it by telling xorg to unconditionally load the respective modules ( I think Load statements in the Server section did the trick ).

Yes, that would work around the issue. But as I mentionned later, it
turns out it's a gcc bug which was fixed upstream, and for which I have
a patch.

And I've been poking around in our dynamic linker, obviously without success,
I thought it's a problem in there since I've seen this bug only on Loongson, but not on sgimips.

It's a bug affecting only N32/N64, but not O32.

I meant N32 on sgimips. Before the latest messup it was almost usable, including X, but unfortunately not gcc.

So it's probably your were lucky :)

Likely ;)

Post by Manuel Bouyer
The bug affetcs only some symbols, in some specific cases.
That's why the loader doesn't complain about all lasy symbols but only one ...

I noticed that it only seemed to affect drivers that would load
submodules ( like xaa and such ). Things like wsfb Just Worked last
time I tried, even on Loongson.


have fun
Michael