Re: [BUG] intel_drv.so fails to load

[Adam Jackson <ajax@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2366 bytes --]

On Wed, 2012-07-18 at 15:07 +0100, Chris Wilson wrote:
> On Wed, 18 Jul 2012 10:02:08 -0400, Adam Jackson <ajax@redhat.com> wrote:
> > On Tue, 2012-07-17 at 22:16 +0100, Chris Wilson wrote:
> > > On Tue, 17 Jul 2012 22:54:38 +0200, Knut Petersen <Knut_Petersen@t-online.de> wrote:
> > > > Some XAA code still waits for a sudden death:
> > > > 
> > > > [ 35756.654] (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
> > > 
> > > 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.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx