On Wed, 2012-07-18 at 15:07 +0100, Chris Wilson wrote: > On Wed, 18 Jul 2012 10:02:08 -0400, Adam Jackson <ajax at 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 at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120718/8877cea6/attachment.pgp>
