All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.