Thread: [Mesa3d-dev] undefined symbols and silent fallback to swrast

Brought to you by: alanh, brianp, chadversary, keithw

mesa3d-dev

[Mesa3d-dev] undefined symbols and silent fallback to swrast

From: Xavier C. <cha...@gm...> - 2010-03-14 23:09:45

14:47 < lb1> the fact is that if you remove a function from mesa .c file,
             everything will succeed, but the resulting driver will fail to load
14:47 < lb1> because it cannot resolve that symbol
14:48 < lb1> not sure why
14:48 < lb1> I suppose even for shared libraries gcc/ld should fail on
             undefined symbols
14:48 < lb1> maybe the makefiles disable that checking

Can anyone shed any light on this, why the driver always succeeds to
build and link even in the case of undefined symbols ?

The second question is why the dlopen errors are not visible by
default and require LIBGL_DEBUG=verbose to be displayed.
It does not make sense to always print these errors by default ?

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

From: tom f. <tf...@al...> - 2010-03-14 23:35:04

Xavier Chantry <cha...@gm...> writes:
> 14:47 < lb1> the fact is that if you remove a function from mesa .c file,
>              everything will succeed, but the resulting driver will fail to l
> oad
> 14:47 < lb1> because it cannot resolve that symbol
> 14:48 < lb1> not sure why
> 14:48 < lb1> I suppose even for shared libraries gcc/ld should fail on
>              undefined symbols
> 14:48 < lb1> maybe the makefiles disable that checking
> 
> Can anyone shed any light on this, why the driver always succeeds to
> build and link even in the case of undefined symbols ?

That's just the default compiler/linker setup on Linux.  This is in
contrast to, say, OS X, where undefined symbols cause link errors.

You can emulate the above by building with -Wl,--no-undefined (or maybe
-no-undefined, something like that, see ld(1)).

> The second question is why the dlopen errors are not visible by
> default and require LIBGL_DEBUG=verbose to be displayed.
> It does not make sense to always print these errors by default ?

Doesn't effect me personally, but errors coming up on stderr does seem
like reasonable default behavior to me.  Is it actually the case that
these are always errors though (i.e. if a dlopen fails, does a higher
level try loading a different driver which might succeed?)?

-tom

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

From: Xavier C. <cha...@gm...> - 2010-03-15 00:01:40

On Mon, Mar 15, 2010 at 12:41 AM, tom fogal <tf...@al...> wrote:
>
> That's just the default compiler/linker setup on Linux.  This is in
> contrast to, say, OS X, where undefined symbols cause link errors.
>
> You can emulate the above by building with -Wl,--no-undefined (or maybe
> -no-undefined, something like that, see ld(1)).
>

Looks like I am entering in a dangerous territory.
With -Wl,--no-undefined, I get so many errors that it did not fit in
my terminal buffer :P
http://paste.pocoo.org/show/189694/

With -Wl,--no-allow-shlib-undefined it's a bit better but it is still scary :

/bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker
'gcc' -ldflags '-Wl,--no-allow-shlib-undefined' \
		../../common/driverfuncs.o ../common/utils.o swrast.o swrast_span.o
 ../../../../../src/mesa/libmesa.a    -ldrm   -lexpat -lm -lpthread
-ldl
mklib: Making Linux shared library:  swrast_dri.so
LDFLAGS : -Wl,--no-allow-shlib-undefined
/lib/libpthread.so.0: undefined reference to `_dl_allocate_tls@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to
`_dl_get_tls_static_info@GLIBC_PRIVATE'
/lib/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../lib/libdl.so:
undefined reference to `_rtld_global_ro@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to `__tls_get_addr@GLIBC_2.3'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../lib/libdrm.so:
undefined reference to `clock_gettime@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../lib/libdl.so:
undefined reference to `_dl_rtld_di_serinfo@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to
`_dl_make_stack_executable@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to
`_dl_allocate_tls_init@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to `_rtld_global@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to `__libc_stack_end@GLIBC_2.2.5'
/lib/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to `_dl_deallocate_tls@GLIBC_PRIVATE'
collect2: ld returned 1 exit status

This is with swrast, but the result with nouveau was quite similar.

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

From: tom f. <tf...@al...> - 2010-03-15 00:12:35

Xavier Chantry <cha...@gm...> writes:
> On Mon, Mar 15, 2010 at 12:41 AM, tom fogal <tf...@al...> wrote:
> >
> > You can emulate the [undefined link errors] by building with
> > -Wl,--no-undefined (or maybe -no-undefined, something like that,
> > see ld(1)).
>
> With -Wl,--no-undefined, I get so many errors that it did not fit in
> my terminal buffer :P
> 
> With -Wl,--no-allow-shlib-undefined it's a bit better but it is still scary :

Oops, sorry; I was thinking of that flag, but I forgot about the shlib
variant && expected --no-undefined to do --no-allow-shlib-undefined.
Anyway, mea culpa, glad you figured out what I meant && not what I said
;)

> /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker
> 'gcc' -ldflags '-Wl,--no-allow-shlib-undefined' \
> 		../../common/driverfuncs.o ../common/utils.o swrast.o swrast_sp
> an.o
>  ../../../../../src/mesa/libmesa.a    -ldrm   -lexpat -lm -lpthread
> -ldl
> mklib: Making Linux shared library:  swrast_dri.so
> LDFLAGS : -Wl,--no-allow-shlib-undefined
> /lib/libpthread.so.0: undefined reference to `_dl_allocate_tls@GLIBC_PRIVATE'
> /lib/libpthread.so.0: undefined reference to
> `_dl_get_tls_static_info@GLIBC_PRIVATE'

These look like TLS issues.

Did you provide --enable-glx-tls to configure?  Looks like you probably
want to, for your platform.

-tom

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

From: Xavier C. <cha...@gm...> - 2010-03-15 00:38:48

On Mon, Mar 15, 2010 at 1:18 AM, tom fogal <tf...@al...> wrote:
> Xavier Chantry <cha...@gm...> writes:
>> /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker
>> 'gcc' -ldflags '-Wl,--no-allow-shlib-undefined' \
>>               ../../common/driverfuncs.o ../common/utils.o swrast.o swrast_sp
>> an.o
>>  ../../../../../src/mesa/libmesa.a    -ldrm   -lexpat -lm -lpthread
>> -ldl
>> mklib: Making Linux shared library:  swrast_dri.so
>> LDFLAGS : -Wl,--no-allow-shlib-undefined
>> /lib/libpthread.so.0: undefined reference to `_dl_allocate_tls@GLIBC_PRIVATE'
>> /lib/libpthread.so.0: undefined reference to
>> `_dl_get_tls_static_info@GLIBC_PRIVATE'
>
> These look like TLS issues.
>
> Did you provide --enable-glx-tls to configure?  Looks like you probably
> want to, for your platform.
>

I did have --enable-glx-tls
I wonder if there are some problems with my system :
$ readelf -s /lib/libpthread.so.0  | grep tls
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_allocate_tls_init@GLIBC_PRIVATE (11)
    29: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_allocate_tls@GLIBC_PRIVATE (11)
    30: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_deallocate_tls@GLIBC_PRIVATE (11)
    39: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
__tls_get_addr@GLIBC_2.3 (15)
    43: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_get_tls_static_info@GLIBC_PRIVATE (11)
   216: 000000000021b308     8 OBJECT  LOCAL  HIDDEN   29 __static_tls_align_m1
   274: 0000000000006390   314 FUNC    LOCAL  HIDDEN   12
__pthread_init_static_tls
   282: 0000000000010e04    12 OBJECT  LOCAL  DEFAULT   15
_thread_db_link_map_l_tls
   396: 000000000021b320     8 OBJECT  LOCAL  HIDDEN   29 __static_tls_size
   457: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_allocate_tls_init@@GL
   552: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_allocate_tls@@GLIBC_P
   555: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_deallocate_tls@@GLIBC
   587: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
__tls_get_addr@@GLIBC_2.3
   625: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_get_tls_static_info@@

Assuming UND means undefined. This does not look too good.
I am curious to know how it looks like on other systems.

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

From: Michel D. <mi...@da...> - 2010-03-15 08:24:00

On Mon, 2010-03-15 at 00:09 +0100, Xavier Chantry wrote: 
> 14:47 < lb1> the fact is that if you remove a function from mesa .c file,
>              everything will succeed, but the resulting driver will fail to load
> 14:47 < lb1> because it cannot resolve that symbol
> 14:48 < lb1> not sure why
> 14:48 < lb1> I suppose even for shared libraries gcc/ld should fail on
>              undefined symbols
> 14:48 < lb1> maybe the makefiles disable that checking
> 
> Can anyone shed any light on this, why the driver always succeeds to
> build and link even in the case of undefined symbols ?

One complication is that the driver needs symbols from libGL and vice
versa. Probably nothing that can't be solved with sufficient
toolchain-fu though.


> The second question is why the dlopen errors are not visible by
> default and require LIBGL_DEBUG=verbose to be displayed.
> It does not make sense to always print these errors by default ?

One problem is that drivers can be loaded from several paths; if the HW
driver fails to load from the first path but succeeds from the next one,
any error messages from the first attempt would be confusing.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

From: Xavier C. <cha...@gm...> - 2010-03-15 12:13:36

2010/3/15 Michel Dänzer <mi...@da...>:
>
> One problem is that drivers can be loaded from several paths; if the HW
> driver fails to load from the first path but succeeds from the next one,
> any error messages from the first attempt would be confusing.
>

If it fails to load because it does not exist ? Or because it exists
but has undefined symbols or other problems ?
It makes sense to not display the first case, but what about the second ?

And what if the driver cannot be found in any places ?

Here are two examples :

1) If swrast can be found

With current mesa master :
libGL error: dlopen /home/xavier/app/mesa/lib/gallium/nouveau_dri.so
failed (/home/xavier/app/mesa/lib/gallium/nouveau_dri.so: undefined
symbol: nv50_transfer_init_screen_functions)
libGL error: dlopen /home/xavier/app/mesa/lib/nouveau_dri.so failed
(/home/xavier/app/mesa/lib/nouveau_dri.so: cannot open shared object
file: No such file or directory)
libGL error: unable to load driver: nouveau_dri.so
libGL error: driver pointer missing
libGL error: dlopen /home/xavier/app/mesa/lib/gallium/swrast_dri.so
failed (/home/xavier/app/mesa/lib/gallium/swrast_dri.so: cannot open
shared object file: No such file or directory)
Mesa: Mesa 7.9-devel DEBUG build Mar 15 2010 01:44:03
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
2623 frames in 5.0 seconds = 524.588 FPS

The first swrast_dri.so error is indeed misleading as it was loaded
fine afterwards. Well we don't need to display that.
libGL error: dlopen /home/xavier/app/mesa/lib/gallium/nouveau_dri.so
failed (/home/xavier/app/mesa/lib/gallium/nouveau_dri.so: undefined
symbol: nv50_transfer_init_screen_functions)
libGL error: unable to load driver: nouveau_dri.so
libGL error: reverting to software direct rendering
Mesa: Mesa 7.9-devel DEBUG build Mar 15 2010 01:44:03
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
2708 frames in 5.0 seconds = 541.526 FPS

2) If swrast cannot be found

libGL error: dlopen /home/xavier/app/mesa/lib/gallium/nouveau_dri.so
failed (/home/xavier/app/mesa/lib/gallium/nouveau_dri.so: undefined
symbol: nv50_transfer_init_screen_functions)
libGL error: dlopen /home/xavier/app/mesa/lib/gallium2/nouveau_dri.so
failed (/home/xavier/app/mesa/lib/gallium2/nouveau_dri.so: cannot open
shared object file: No such file or directory)
libGL error: unable to load driver: nouveau_dri.so
libGL error: driver pointer missing
libGL error: dlopen /home/xavier/app/mesa/lib/gallium/swrast_dri.so
failed (/home/xavier/app/mesa/lib/gallium/swrast_dri.so: cannot open
shared object file: No such file or directory)
libGL error: dlopen /home/xavier/app/mesa/lib/gallium2/swrast_dri.so
failed (/home/xavier/app/mesa/lib/gallium2/swrast_dri.so: cannot open
shared object file: No such file or directory)
libGL error: unable to load driver: swrast_dri.so
libGL error: reverting to indirect rendering
3299 frames in 5.0 seconds = 658.631 FPS

could be changed to :
libGL error: dlopen /home/xavier/app/mesa/lib/gallium/nouveau_dri.so
failed (/home/xavier/app/mesa/lib/gallium/nouveau_dri.so: undefined
symbol: nv50_transfer_init_screen_functions)
libGL error: unable to load driver: nouveau_dri.so
libGL error: reverting to software direct rendering
libGL error: swrast_dri.so not found in
/home/xavier/app/mesa/lib/gallium:/home/xavier/app/mesa/lib/gallium2
libGL error: unable to load driver: swrast_dri.so
libGL error: reverting to indirect rendering
2981 frames in 5.1 seconds = 590.078 FPS


In these two examples I only compared the different behavior with
swrast which is a valid driver, but can either be found or not.
nouveau_dri is invalid however with undefined symbols, any reason for
not displaying that all the time ?

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

From: Luca B. <lu...@lu...> - 2010-03-15 13:36:53

Adding both -Wl,--no-undefined and -lGL (in
src/gallium/winsys/drm/Makefile.template) seems to work for me.

The driver loader is already loading libGL.so.1 with RTLD_NOW |
RTLD_GLOBAL, so I think that the DRI driver depending on libGL.so.1
shouldn't introduce any issue.

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

From: Xavier C. <cha...@gm...> - 2010-03-15 13:45:50

On Mon, Mar 15, 2010 at 2:30 PM, Luca Barbieri <lu...@lu...> wrote:
> Adding both -Wl,--no-undefined and -lGL (in
> src/gallium/winsys/drm/Makefile.template) seems to work for me.
>

Oh great, that works for me too !

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

From: Michel D. <mi...@da...> - 2010-03-15 15:07:11

On Mon, 2010-03-15 at 14:30 +0100, Luca Barbieri wrote: 
> Adding both -Wl,--no-undefined and -lGL (in
> src/gallium/winsys/drm/Makefile.template) seems to work for me.
> 
> The driver loader is already loading libGL.so.1 with RTLD_NOW |
> RTLD_GLOBAL, so I think that the DRI driver depending on libGL.so.1
> shouldn't introduce any issue.

Keep in mind the AIGLX case. Loading libGL into the X server probably
isn't desirable.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer