Ok, pushed yet another patch to reimplement those tables within i810. I
couldn't spot any more obvious XAA functions called from i810_accel, so
hopefully this will be the last iteration!
Sigh. Wish you hadn't, the linker behaviour he's seeing is _broken_.
Just because we don't know why doesn't make it not a bug.
Except it also meant that i810 was indeed broken since it was unusing
undefined symbols.
No, not the case.
Normal ELF behaviour is that external data references are resolved at
object load time, but that function references are resolved when they
are first called; this is an optimization for app startup time. The
former case is not what's going on here, because we're not taking the
address of XAAGetPatternROP (a data reference), we're calling it (a
function reference):
hate:~/driver/xf86-video-intel% git grep XAAGetPatternROP
src/legacy/i810/i810_accel.c: (XAAGetPatternROP(rop) << 16) |
src/legacy/i810/i810_xaa.c: pI810->BR[13] |= XAAGetPatternROP(rop) << 16;
So those should resolve lazily, which means if you never call them they
never _need_ to resolve. And this is how X drivers normally work,
notice that libfb isn't loaded _before_ you load your driver but yet the
driver loads.
And we know the failure case here is not "failing to lazily resolve",
because if we were hitting _that_ we wouldn't see the error message he's
seeing, ld.so would just bitch on stderr and _exit(). The error message
he's seeing is dlopen() failing.
So this really honestly is a toolchain problem, not a driver problem.
Knut, can you send me a copy of your driver binary? I'm really curious
to see where that data reference is coming from, assuming BIND_NOW is
not what we're seeing.
Ok, I built caef63e0268e59e439b030a9a338e81d5cf8e311 using
export MYROOT=/home/knut/git/X11-t
export PREFIX=$MYROOT/usr
export EPREFIX=$PREFIX
export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PREFIX/share/pkgconfig
export PATH=$PREFIX/bin:$PATH
export ACLOCAL="aclocal -I $PREFIX/share/aclocal"
export LD_LIBRARY_PATH=$PREFIX/lib
export PYTHONPATH=$PREFIX/lib/python2.7/site-packages
export MAKEFLAGS="-j 15"
export GMAKEFLAGS="-j 15"
export CC=/opt/icecream/bin/gcc
export CXX=/opt/icecream/bin/g++
export CFLAGS="-g2 -O3 --verbose -D MULTITOUCH"
export CXXFLAGS="-g2 -O3 "
export LD_PRELOAD=$PREFIX/lib/libmtdev.so
util/modular/build.sh -g $PREFIX -o driver/xf86-video-intel --confflags
"--disable-xaa --localstatedir=$MYROOT/var"
and got the following log entries:
[107706.682] (II) LoadModule: "intel"
[107706.682] (II) Loading
/home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so
[107706.700] (EE) Failed to load
/home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so:
/home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so: undefined
symbol: XAAGetPatternROP
[107706.700] (II) UnloadModule: "intel"
[107706.700] (II) Unloading intel
[107706.700] (EE) Failed to load module "intel" (loader failed, 7)
[107706.700] (EE) No drivers available.
[107706.709]
Fatal server error:
[107706.709] no screens found
Bad behaviour restored.
I modified my run script to contain LD_DEBUG*
export PREFIX=/home/knut/git/X11-t/usr
export PATH=$PREFIX/bin:$PATH
export LD_LIBRARY_PATH=$PREFIX/lib
export LD_PRELOAD=$PREFIX/lib/libmtdev.so
export LD_DEBUG=all
export LD_DEBUG_OUTPUT=/home/knut/git/X11-t/ld_debug_output
/home/knut/startx -- $PREFIX/bin/Xorg
and executed it as root. Xorg still fails (nothing else had to be expected).
The log is too big for the mailing list, but:
knut@golem:~/git/X11-t> grep "relocation processing" ld_debug_output.28936
28936: relocation processing: /lib/libc.so.6
28936: relocation processing: /lib/libgpg-error.so.0 (lazy)
28936: relocation processing: /lib/libpthread.so.0 (lazy)
28936: relocation processing: /lib/librt.so.1 (lazy)
28936: relocation processing: /lib/libm.so.6 (lazy)
28936: relocation processing:
/home/knut/git/X11-t/usr/lib/libXdmcp.so.6 (lazy)
28936: relocation processing: /home/knut/git/X11-t/usr/lib/libXau.so.6
(lazy)
28936: relocation processing: /lib/libz.so.1
28936: relocation processing:
/home/knut/git/X11-t/usr/lib/libfontenc.so.1 (lazy)
28936: relocation processing: /usr/lib/libfreetype.so.6 (lazy)
28936: relocation processing:
/home/knut/git/X11-t/usr/lib/libXfont.so.1 (lazy)
28936: relocation processing:
/home/knut/git/X11-t/usr/lib/libpixman-1.so.0 (lazy)
28936: relocation processing: /home/knut/git/X11-t/usr/lib/libdrm.so.2
(lazy)
28936: relocation processing:
/home/knut/git/X11-t/usr/lib/libpciaccess.so.0 (lazy)
28936: relocation processing: /lib/libdl.so.2 (lazy)
28936: relocation processing: /lib/libgcrypt.so.11 (lazy)
28936: relocation processing: /lib/libudev.so.0 (lazy)
28936: relocation processing: /home/knut/git/X11-t/usr/lib/libmtdev.so
(lazy)
28936: relocation processing: /home/knut/git/X11-t/usr/bin/Xorg (lazy)
28936: relocation processing: /lib/ld-linux.so.2
28936: relocation processing: /lib/libgcc_s.so.1 (lazy)
28936: relocation processing:
/home/knut/git/X11-t/usr/lib/xorg/modules/libvgahw.so (lazy)
28936: relocation processing:
/home/knut/git/X11-t/usr/lib/xorg/modules/libfb.so (lazy)
28936: relocation processing:
/home/knut/git/X11-t/usr/lib/xorg/modules/libint10.so (lazy)
28936: relocation processing:
/home/knut/git/X11-t/usr/lib/xorg/modules/libvbe.so (lazy)
28936: relocation processing:
/home/knut/git/X11-t/usr/lib/xorg/modules/libshadowfb.so (lazy)
28936: relocation processing:
/home/knut/git/X11-t/usr/lib/xorg/modules/extensions/libglx.so (lazy)
28936: relocation processing:
/home/knut/git/X11-t/usr/lib/libdrm_intel.so.1 (lazy)
28936: relocation processing:
/home/knut/git/X11-t/usr/lib/xorg/modules/drivers/intel_drv.so (lazy)
So relocation processing is done LAZY. At least that´s what the tool believes.
This is an opensuse system. All tools are those from the distro,
I´m not the only one using them. My system behaves this way in
version 12.1, and it behaved so in 11.4.
I have absolutely no idea why ld seems to fail in lazy relocation processing.
Adam, you´ll receive the binary and the full ld log as pm.
cu,
Knut
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
