[Intel-gfx] [BUG] intel_drv.so fails to load
Knut Petersen
Knut_Petersen at t-online.de
Wed Jul 18 20:04:18 CEST 2012
>>>> 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 at 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
More information about the Intel-gfx
mailing list