public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Knut Petersen <Knut_Petersen@t-online.de>
To: Adam Jackson <ajax@redhat.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [BUG] intel_drv.so fails to load
Date: Wed, 18 Jul 2012 20:04:18 +0200	[thread overview]
Message-ID: <5006FAA2.2090803@t-online.de> (raw)
In-Reply-To: <1342621766.3590.29.camel@atropine>


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

  parent reply	other threads:[~2012-07-18 18:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-17 20:08 [BUG] intel_drv.so fails to load Knut Petersen
2012-07-17 20:16 ` Chris Wilson
2012-07-17 20:41   ` Chris Wilson
2012-07-17 20:54     ` Knut Petersen
2012-07-17 21:11       ` Adam Jackson
2012-07-17 21:34         ` Knut Petersen
2012-07-17 21:16       ` Chris Wilson
2012-07-17 21:52         ` Knut Petersen
2012-07-18 14:02         ` Adam Jackson
2012-07-18 14:07           ` Chris Wilson
2012-07-18 14:29             ` Adam Jackson
2012-07-18 14:36               ` Chris Wilson
2012-07-18 19:47                 ` Adam Jackson
2012-07-18 22:34                   ` Chris Wilson
2012-07-19 14:08                     ` Adam Jackson
2012-07-18 18:04               ` Knut Petersen [this message]
2012-07-18 19:34                 ` Adam Jackson
2012-07-19  6:04                   ` Knut Petersen
2012-07-20 12:03               ` Knut Petersen
2012-07-20 15:10                 ` Adam Jackson
2012-07-20 16:01                   ` Knut Petersen
2012-07-17 20:41   ` Knut Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5006FAA2.2090803@t-online.de \
    --to=knut_petersen@t-online.de \
    --cc=ajax@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox