[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

GitLab Migration User  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #18 from GitLab Migration User  ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/236.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

Adam Jackson  changed:

   What|Removed |Added

  Component|Drivers/X11 |Drivers/Gallium/llvmpipe

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #17 from fiach.an...@gmail.com ---
I've run into a variant of this bug where when using swrast, symbols from a
shared object linked by LLVM (libedit) conflict with symbols from a shared
object used by a client application (readline/python). In general opening a
shared object with RTLD_GLOBAL appears to propagate that flag to all
dependencies of that object, which means that even with LLVM adopting versioned
symbols problems may still occur due to LLVM dependencies. I've attached a
reduced test-case which shows the issue (llvm-libedit-bug.py).

Is it possible to dlopen DRI drivers as RTLD_LOCAL? The original RTLD_LOCAL
patch had to be reverted (#79469) due to client software not dlopening
libglapi.so, but opening the DRI drivers as RTLD_LOCAL seems like it should
still work.

Failing that, if building with --disable-llvm-shared-libs fixes the issue, it
should either be the default or (preferably) required. Unfortunately I can't
seem to get that option to work for me on
62a819184141133478cfdcfa76b62d5bb7e14fd5 with the set of configure options
listed below (ldd shows that swrast_dri.so still imports libLLVM-3.9.so.1, and
the test case still fails with the same root cause):

./configure --build=x86_64-linux-gnu \
--prefix=/usr \
--includedir=/usr/include \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--sysconfdir=/etc \
--localstatedir=/var \
--disable-silent-rules \
--libdir=/usr/lib/x86_64-linux-gnu \
--libexecdir=/usr/lib/x86_64-linux-gnu \
--disable-dependency-tracking \
--disable-llvm-shared-libs \
"--with-dri-drivers= nouveau i915 i965 r200 radeon" \
--with-dri-driverdir=/usr/lib/x86_64-linux-gnu/dri \
--with-dri-searchpath=/usr/lib/x86_64-linux-gnu/dri:/usr/lib/dri \
--with-sha1=libmd \
"--with-vulkan-drivers= intel radeon" \
--enable-osmesa \
--enable-texture-float \
--disable-xvmc \
--enable-driglx-direct \
--enable-dri3 \
"--with-egl-platforms=x11 wayland drm" \
--enable-xa \
--enable-opencl \
--enable-opencl-icd \
--enable-gallium-llvm \
--enable-vdpau \
--enable-va \
--enable-gallium-extra-hud \
--enable-lmsensors \
"--with-gallium-drivers= nouveau svga virgl r600 r300 radeonsi swrast"
\
ac_cv_path_LLVM_CONFIG=llvm-config-3.9

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #16 from fiach.an...@gmail.com ---
Created attachment 128707
  --> https://bugs.freedesktop.org/attachment.cgi?id=128707=edit
Test-case for global symbol contamination due to LLVM dependency.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

Vedran Miletić  changed:

   What|Removed |Added

 CC||ved...@miletic.net

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

Jan Ziak <0xe2.0x9a.0...@gmail.com> changed:

   What|Removed |Added

 CC||0xe2.0x9a.0...@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #15 from Emil Velikov  ---
The commit mentioned addresses only their autoconf (more like gnumake really)
build. Current upstream covers both builds with should be identical
auto-generated (?) LD version scripts.

Small aside (C symbols): on my system llvm 3.7 provides some 130+ that are not
part of the API. This is 20% of out of the total ~800 (note: haven't checked
for preprocessor macros).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #14 from Michel Dänzer  ---
FWIW, IME LLVM's symbol versioning seems to only help if all LLVM libraries
involved have versioned symbols. I did verify at one point with gambas that
radeonsi using a different LLVM library from gambas worked if both LLVM
libraries had versioned symbols but broke if the LLVM library used by gambas
didn't have versioned symbols.

BTW, the LLVM symbol versioning was introduced by
http://www.llvm.org/viewvc/llvm-project?view=revision=214418 , but I'm
not sure if that's already active with a cmake build as well or if something
needs to be done for that.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #5 from Tobias Schlüter  ---
Thank you for the quick response!  I'll take the comments to mean that this
shouldn't happen with very recent versions of libmesa and llvm.  It does happen
with fairly recent versions though.

We verified on a colleague's system that the same error appears on Ubuntu 15.05
with libmesa 10.5.9 and libllvm 3.6, (there are some differences in the
backtrace because we used a slightly simpler way of triggering the bug as
documented in the ROOT bug report I was linking to).  I would be surprised if
Ubuntu uses scons for the build, but I don't know.  Backtrace:
===
#5  0x7f5c3a87de31 in llvm::cl::AddLiteralOption(llvm::cl::Option&, char
const*) () from
/home/ritter/belle2/externals/development/Linux_x86_64/opt/root/lib/libCling.so
#6  0x7f5c2d944e3a in
llvm::PassRegistry::enumerateWith(llvm::PassRegistrationListener*) () from
/usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1
#7  0x7f5c2d6e86a8 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1
#8  0x7f5c3d4585ba in ?? () from /lib64/ld-linux-x86-64.so.2
#9  0x7f5c3d4586cb in ?? () from /lib64/ld-linux-x86-64.so.2
#10 0x7f5c3d45d587 in ?? () from /lib64/ld-linux-x86-64.so.2
#11 0x7f5c3d458464 in ?? () from /lib64/ld-linux-x86-64.so.2
#12 0x7f5c3d45c9a3 in ?? () from /lib64/ld-linux-x86-64.so.2
#13 0x7f5c3bea5fc9 in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
#14 0x7f5c3d458464 in ?? () from /lib64/ld-linux-x86-64.so.2
#15 0x7f5c3bea662d in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
#16 0x7f5c3bea6061 in dlopen () from /lib/x86_64-linux-gnu/libdl.so.2
#17 0x7f5c3938c47f in cling::DynamicLibraryManager::loadLibrary(std::string
const&, bool) () from
/home/ritter/belle2/externals/development/Linux_x86_64/opt/root/lib/libCling.so
...


I don't agree with Emil that it is a problem on the ROOT side (even though the
installed a workaround): one should be able to use libmesa without being afraid
that symbols leak through that are not part of libmesa's public interface.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #6 from Emil Velikov  ---
(In reply to Tobias Schlüter from comment #5)
> Thank you for the quick response!  I'll take the comments to mean that this
> shouldn't happen with very recent versions of libmesa and llvm.  It does
> happen with fairly recent versions though.
> 
A "global" (affecting all drivers) version script has been added in mesa circa
10.2.

> We verified on a colleague's system that the same error appears on Ubuntu
> 15.05 with libmesa 10.5.9 and libllvm 3.6, (there are some differences in
> the backtrace because we used a slightly simpler way of triggering the bug
> as documented in the ROOT bug report I was linking to).  I would be
> surprised if Ubuntu uses scons for the build, but I don't know.

Pretty much every Linux distributions uses the autotools.

Check, if ever in doubt about the exposed symbols.

libGL itself
$ nm -CD --defined-only /lib/libGL.so | grep -v " gl"
002969c8 b __bss_start
002969c8 d _edata
00297480 b _end
00074c54 T _fini
0004e9d0 T _glapi_create_table_from_handle
00017338 T _init


DRI module, used by libGL (do check all the "*_dri.so" found in /lib)
$ nm -CD --defined-only /lib/xorg/modules/dri/swrast_dri.so
00642e60 T amdgpu_winsys_create
00a62480 B __driDriverExtensions
00073510 T __driDriverGetExtensions_kms_swrast
000735d0 T __driDriverGetExtensions_nouveau
000735f0 T __driDriverGetExtensions_r300
00073610 T __driDriverGetExtensions_r600
00073630 T __driDriverGetExtensions_radeonsi
00073440 T __driDriverGetExtensions_swrast
00073650 T __driDriverGetExtensions_vmwgfx
003fa060 T nouveau_drm_screen_create
0062c9b0 T radeon_drm_winsys_create

As you can see, nothing from LLVM/Clang is explicitly exported/leaked.

> 
> I don't agree with Emil that it is a problem on the ROOT side (even though
> the installed a workaround): one should be able to use libmesa without being
> afraid that symbols leak through that are not part of libmesa's public
> interface.

First and foremost I would encourage you to try with statically linked LLVM as
Jose suggested.

On the actual issue and who's "doing things wrong" it's a combination of bugs
and suboptimal decisions:

 1 To avoid pollution of (conflicts in) global namespace, people must make sure
that they hide their symbols - as done with the ROOT report. Imho this is a
must fix.

 2 Mesa should not dlopen its module with RTLD_GLOBAL. This in itself may
pollute the global namespace (haven't checked), despite that we've hidden the
exported symbols.

 3 Using private libraries conflicting(incompatible) with the system ones is a
very bad idea. If needed one can 1) static link the private ones in their
application or 2) do LD_PRELOAD/LD_LIBRARY_PATH/RPATH magic to ensure the
correct libraries are loaded.

Fixing this on the client side is trivial (both 1 and 3.1). I'm afraid that
fixing the one in mesa is a lot more convoluted than the patch in comment 2 -
we tried and quickly had to revert it :-(

Not saying that mesa is perfect - on the contrary we should drop the
RTLD_GLOBAL hack. Then again others could do their fair share in keeping things
sane.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #7 from Jose Fonseca  ---
I wonder if Tobias is using XLIB-based libGL.so.1, as opposed to the DRI based
libGL.so.1.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #8 from Emil Velikov  ---
(In reply to Jose Fonseca from comment #7)
> I wonder if Tobias is using XLIB-based libGL.so.1, as opposed to the DRI
> based libGL.so.1.

I fixed that one got around mesa 10.3 - see
src/gallium/targets/libgl-xlib/libgl-xlib.sym. I've been a good boy cleaning
there up :-P

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #9 from Jose Fonseca  ---
(In reply to Emil Velikov from comment #6)
> Check, if ever in doubt about the exposed symbols.
> 
> libGL itself
> $ nm -CD --defined-only /lib/libGL.so | grep -v " gl"
[...]
>
> DRI module, used by libGL (do check all the "*_dri.so" found in /lib)
> $ nm -CD --defined-only /lib/xorg/modules/dri/swrast_dri.so
[...]
> 
> As you can see, nothing from LLVM/Clang is explicitly exported/leaked.


My understanding from Tobias description is that the LLVM symbols from
/usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1 are clashing with a custom LLVM
build for cling -- https://root.cern.ch/cling-build-instructions

The real question is what symbols libLLVM-3.6.so provides, and 

$ nm -CD --defined-only /usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1

shows lot of them.


LLVM is used in lots of projects nowadays -- language interpreters, etc.   So
are OpenGL drivers -- they get loaded in all sort of processes.  So when distro
decided to use a shared LLVM for the opengl drivers to save a few bytes, they
basically gave the finger to everybody who needs to use bleeding edge LLVM and
OpenGL...


(In reply to Emil Velikov from comment #3)
> > In addition to that, we probably also need to use a LD version script to
> > ensure that LLVM symbols don't pop in the dynamic symbol table.
> We have those for a while. 

I'm not sure it helps if the problem is is
/usr/lib/x86_64-linux-gnu/libLLVM-3.4.so.1  .  The only solution is if the
system libLLVM-X.X.so an unique symbol version/namespace, or maybe the
RTLD_LOCAL as you mentioned.

> Atm only the autotools build uses them (hint hint
> scons).

Sure.  I'll look into it.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #10 from Tobias Schlüter  ---
Probably no longer relevant per #8, and I don't know how to tell different
libGL.so.1 apart with certainty, but I guess you can do this based on ldd
output, so here goes (DRI appears, Xlib doesn't):
$ ldd /usr/lib/x86_64-linux-gnu/mesa/libGL.so
linux-vdso.so.1 =>  (0x7ffe71b89000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0
(0x7f118cf53000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x7f118cd41000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1
(0x7f118cb3e000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3
(0x7f118c938000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1
(0x7f118c736000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7f118c401000)
libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0
(0x7f118c1ea000)
libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0
(0x7f118bfe5000)
libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0
(0x7f118bde2000)
libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0
(0x7f118bbdf000)
libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1
(0x7f118b9d9000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x7f118b7ba000)
libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1
(0x7f118b5b8000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1
(0x7f118b3b2000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x7f118b1a6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f118af88000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f118ad84000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f118a9bf000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x7f118a7bb000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
(0x7f118a5b5000)
/lib64/ld-linux-x86-64.so.2 (0x7f118d3e)
$

Concerning #6, from which I learnt a lot, thank you for that, two comments:
1) I wouldn't consider it good practice to redefine LLVM as a "system library"
and then blame problems related to it on users
2) I guess I could read your comment as saying that the bug lies with LLVM as
they (at least up to version 3.6) don't version their symbols correct (though
from a user-experience side there is an issue with libmesa, even if it is
inherited)

I have pointed the ROOT people to this bug report, I hope they can draw their
conclusions from this.  We're currently setting up mesa 11 and the latest
version of ROOT, and I will report back.

ps concerning the choices about who should statically link, I agree with #9
(submitted while I was putting this comment together).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #11 from Emil Velikov  ---
(In reply to Jose Fonseca from comment #9)

> $ nm -CD --defined-only /usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1
> 
> shows lot of them.
> 
I have the very vague memory that older versions of LLVM exported internal
symbols as well. Perhaps this bug is related to that defect ?

> So when
> distro decided to use a shared LLVM for the opengl drivers to save a few
> bytes, they basically gave the finger to everybody who needs to use bleeding
> edge LLVM and OpenGL...
> 
Not much we can do there I'm afraid. Distros have their policies and we have
the config switch for people to go the route they like.

> 
> (In reply to Emil Velikov from comment #3)
> > > In addition to that, we probably also need to use a LD version script to
> > > ensure that LLVM symbols don't pop in the dynamic symbol table.
> > We have those for a while. 
> 
> I'm not sure it helps if the problem is is
> /usr/lib/x86_64-linux-gnu/libLLVM-3.4.so.1  .  The only solution is if the
> system libLLVM-X.X.so an unique symbol version/namespace, or maybe the
> RTLD_LOCAL as you mentioned.
>
Michel mentioned that llvm 3.6 has versioned symbols, although I cannot see any
tag in my Archlinux cmake llvm 3.7 build. I do see a very nasty looking RPATH
though - $ORIGIN/../lib ... ouch.

> > Atm only the autotools build uses them (hint hint
> > scons).
> 
> Sure.  I'll look into it.

Thank you !

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #12 from Emil Velikov  ---
(In reply to Tobias Schlüter from comment #10)
> Probably no longer relevant per #8, and I don't know how to tell different
> libGL.so.1 apart with certainty, but I guess you can do this based on ldd
> output, so here goes (DRI appears, Xlib doesn't):
> $ ldd /usr/lib/x86_64-linux-gnu/mesa/libGL.so

>   libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0
Based on this I'd say 

> (0x7f118cf53000)
>   libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 
> (0x7f118cd41000)
>   libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1
> (0x7f118cb3e000)
>   libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3
> (0x7f118c938000)
>   libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1
> (0x7f118c736000)
>   libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 
> (0x7f118c401000)
>   libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0
> (0x7f118c1ea000)
>   libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0
> (0x7f118bfe5000)
>   libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0
> (0x7f118bde2000)
>   libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0
> (0x7f118bbdf000)
>   libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1
> (0x7f118b9d9000)
>   libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 
> (0x7f118b7ba000)
>   libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1
> (0x7f118b5b8000)
>   libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1
> (0x7f118b3b2000)
>   libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 
> (0x7f118b1a6000)
>   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f118af88000)
>   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f118ad84000)
>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f118a9bf000)
>   libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 
> (0x7f118a7bb000)
>   libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
> (0x7f118a5b5000)
>   /lib64/ld-linux-x86-64.so.2 (0x7f118d3e)
> $
> 
> Concerning #6, from which I learnt a lot, thank you for that, two comments:
Glad to hear.

> 1) I wouldn't consider it good practice to redefine LLVM as a "system
> library" and then blame problems related to it on users
In my view once any library is installed system wide it can be considered
"system". As to who and why did that is not a another question for me to answer
;-)

> 2) I guess I could read your comment as saying that the bug lies with LLVM
> as they (at least up to version 3.6) don't version their symbols correct
> (though from a user-experience side there is an issue with libmesa, even if
> it is inherited)
> 
That plus the possible RTLD_GLOBAL issue. On the good side I should be looking
into our end soonish.

> I have pointed the ROOT people to this bug report, I hope they can draw
> their conclusions from this.  We're currently setting up mesa 11 and the
> latest version of ROOT, and I will report back.
> 
> ps concerning the choices about who should statically link, I agree with #9
> (submitted while I was putting this comment together).
Great, good luck (in an honest, non sarcastic way).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #13 from Tobias Schlüter  ---
(In reply to Emil Velikov from comment #12)
> (In reply to Tobias Schlüter from comment #10)
> > I have pointed the ROOT people to this bug report, I hope they can draw
> > their conclusions from this.  We're currently setting up mesa 11 and the
> > latest version of ROOT, and I will report back.
> Great, good luck (in an honest, non sarcastic way).

Thanks, they seem to work together, at least the simple crash-provoking
mechanism fails there.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #2 from Emil Velikov  ---
Hmm I'm pretty sure that I removed all of those an year or two ago. 

And looking at the patches in said report, it seems that it was a problem on
their end -> they were not hiding the (should be) internal symbols.

The only thing that can remotely cause problems is that we dlopen(RTLD_GLOBAL)
the module which internally references LLVM. You can try the following patch,
although we cannot get it upstream without some serious work or we'll break a
lot of applications.



diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index 8a56385..2c2eef6 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -103,7 +103,7 @@ driOpenDriver(const char *driverName)
int len;

/* Attempt to make sure libGL symbols will be visible to the driver */
-   glhandle = dlopen(GL_LIB_NAME, RTLD_NOW | RTLD_GLOBAL);
+   glhandle = dlopen(GL_LIB_NAME, RTLD_NOW | RTLD_LOCAL);

libPaths = NULL;
if (geteuid() == getuid()) {
@@ -131,14 +131,14 @@ driOpenDriver(const char *driverName)
   snprintf(realDriverName, sizeof realDriverName,
"%.*s/tls/%s_dri.so", len, p, driverName);
   InfoMessageF("OpenDriver: trying %s\n", realDriverName);
-  handle = dlopen(realDriverName, RTLD_NOW | RTLD_GLOBAL);
+  handle = dlopen(realDriverName, RTLD_NOW | RTLD_LOCAL);
 #endif

   if (handle == NULL) {
  snprintf(realDriverName, sizeof realDriverName,
   "%.*s/%s_dri.so", len, p, driverName);
  InfoMessageF("OpenDriver: trying %s\n", realDriverName);
- handle = dlopen(realDriverName, RTLD_NOW | RTLD_GLOBAL);
+ handle = dlopen(realDriverName, RTLD_NOW | RTLD_LOCAL);
   }

   if (handle != NULL)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #3 from Emil Velikov  ---
(In reply to Jose Fonseca from comment #1)

> In addition to that, we probably also need to use a LD version script to
> ensure that LLVM symbols don't pop in the dynamic symbol table.
We have those for a while. Atm only the autotools build uses them (hint hint
scons).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

Jose Fonseca  changed:

   What|Removed |Added

 CC||jfons...@vmware.com

--- Comment #1 from Jose Fonseca  ---
I said over and over again that building Mesa drivers with shared LLVM library
(as opposed to statically linked) was a bad idea.

You need to build with

  --disable-llvm-shared-libs

and lobby the Linux distributions to not do it.


In addition to that, we probably also need to use a LD version script to ensure
that LLVM symbols don't pop in the dynamic symbol table.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

Bug ID: 93103
   Summary: llvm symbols leak through, cause trouble with software
rendering in llvm-linked software
   Product: Mesa
   Version: 10.1
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/X11
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: t...@schlueters.de
QA Contact: mesa-dev@lists.freedesktop.org

libmesa uses llvm in its software rendering path.  I'm trying to run via X
forwarding (and thus using software rendering) a software project on ubuntu
14.04 that uses OpenGL for visualization and links against its own copy of llvm
(via the root libraries, I don't think this matters, and they have recently put
in place a workaround for this problem, their bug report is here
https://sft.its.cern.ch/jira/browse/ROOT-7744).

When loading the mesa libraries I get a backtrace that looks as follows
(libCling is the interface to llvm):
#5  0x7f3eff60deb1 in llvm::cl::AddLiteralOption(llvm::cl::Option&, char
const*) () from
/home/schlueter/src/belle2/externals/v01-01-01/Linux_x86_64/opt/root/lib/libCling.so
#6  0x7f3ecadcfdcc in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-3.4.so.1
#7  0x7f3f0867913a in ?? () from /lib64/ld-linux-x86-64.so.2
#8  0x7f3f08679223 in ?? () from /lib64/ld-linux-x86-64.so.2
#9  0x7f3f0867dc70 in ?? () from /lib64/ld-linux-x86-64.so.2
#10 0x7f3f08678ff4 in ?? () from /lib64/ld-linux-x86-64.so.2
#11 0x7f3f0867d3bb in ?? () from /lib64/ld-linux-x86-64.so.2
#12 0x7f3f06cd902b in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
#13 0x7f3f08678ff4 in ?? () from /lib64/ld-linux-x86-64.so.2
#14 0x7f3f06cd962d in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
#15 0x7f3f06cd90c1 in dlopen () from /lib/x86_64-linux-gnu/libdl.so.2
#16 0x7f3edc84801c in ?? () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#17 0x7f3edc847719 in ?? () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#18 0x7f3edc828558 in ?? () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#19 0x7f3edc824f3b in ?? () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#20 0x7f3edc8256d0 in glXChooseVisual () from
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#21 0x7f3eddc7ffc1 in TGLWidget::CreateWindow(TGWindow const*, TGLFormat
const&, unsigned int, unsigned int, std::pair&) () from
/home/schlueter/src/belle2/externals/v01-01-01/Linux_x86_64/opt/root/lib/libRGL.so
#22 0x7f3eddc80500 in TGLWidget::Create(TGLFormat const&, TGWindow const*,
bool, bool, TGLPaintDevice const*, unsigned int, unsigned int) () from
/home/schlueter/src/belle2/externals/v01-01-01/Linux_x86_64/opt/root/lib/libRGL.so
#23 0x7f3eddc80723 in TGLWidget::Create(TGWindow const*, bool, bool,
TGLPaintDevice const*, unsigned int, unsigned int) () from
/home/schlueter/src/belle2/externals/v01-01-01/Linux_x86_64/opt/root/lib/libRGL.so
#24 0x7f3eddbf4801 in TGLEmbeddedViewer::CreateFrames() () from
/home/schlueter/src/belle2/externals/v01-01-01/Linux_x86_64/opt/root/lib/libRGL.so

The reason is that the symbols from the libllvm that libmesa is linked against
collide with the symbols of my already loaded llvm library.  I don't think
libmesa should load libraries in a way that pollutes the symbol namespace,
depending on the execution path taken.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93103

--- Comment #4 from Michel Dänzer  ---
Also note that as of version 3.6, LLVM uses versioned symbols, which may help
for this issue.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev