On Wed, May 01, 2013 at 04:11:51PM +0200, Mathias Fröhlich wrote: > > Tom, Jose, > > On Tuesday, April 30, 2013 16:56:56 Tom Stellard wrote: > > I took the linker script from your email and took at shot at creating > > libMesaLLVM.so within Mesa. I've pushed my initial code here: > > http://cgit.freedesktop.org/~tstellar/mesa/log/?h=libmesallvm > Thank you very much and sorry for the late reply. > > > I ran into a few minor issues: > > > > I had to export all the LLVM symbols in libMesaLLVM.so, because gallivm > > still uses some C++ functions, and I was unsure how to handle the name > > mangling in the linker script. > You can even add c++ symbols directly there. See > http://sourceware.org/binutils/docs/ld/VERSION.html >
Thanks for pointing this out, I'll look into it. Do you know if there is any way to add C++ symbols to the EXPORT() command? > > Clover still has a number of undefined symbols. I'm still not quite > > sure what the problem is, but I think the problem has something > > to do with the LLVM symbols in the clang libraries clover is using. > Also not sure, but I assume that some .o files from the .a libs are not > pulled > because they are unused by the C api. The C api is explicitly pulled in the > linker script. Which works around the lack of --whole-archive in the linker > script. So, probably these missing symbols do just not end up in the shared > library. > Yeah, this was the problem, clang needed symbols that weren't used by the C API, so they weren't included in libMesaLLVM.so. > > I didn't do much testing yet, but glxgears works for me with r600g and > > llvmpipe. > I tried to test against the driver-isolation piglit test that I sent. But > this > still fails. > > So, this simplest and least intrusive variant appears not to work as expected. > Not sure what the exact reason is: > Either, non versioned symbols take precedence or you cannot shield symbols > from different libraries by symbol versions. Keep in mind that this mechanism > was invented to maintain backwards compatibility for functions that changed > in > a newer libc library in a api incompatible way, but still provide the old > variant for executables/libraries that linked against an older libc. > So what remains is either dig deeper there, or we use the much more intrusive > explicit Mesa prefix to the C api functions. The direct c++ use is still > unsolved then. > Today, I spent some time on this and implemented your solution using the MesaLLVM prefix on all LLVM functions. The branch is here: http://cgit.freedesktop.org/~tstellar/mesa/log/?h=libmesallvm-prefix It's pretty hacky right now. Only the r600 driver will build, and I've commented all the c++ code out of gallivm. However, it passes your driver-isolation test and even works with clover as long as clover links to the stock libLLVM-3.3.so library. We still need to figure out what to do about he c++ usage. I think some of it can be replaced with LLVM C API calls, but we may need to use our own C wrappers for some of the code. It seems like the prefixing the LLVM calls may be the way to go, let me know if you have any suggestions for improvements. -Tom > > Also, note that there are 4 new commits in that repo, the first three > > are just variations from my previous C API patches for drivers/radeon. > > The biggest change is that I moved the static initializer that calls > > the llvm_multithreaded* functions into gallivm/lp_bld_misc.cpp > From my point of view this part is fine. > > > Let me know if you have any questions, concerns or other ideas. > Currently not. > Thank you for integrating that all and trying that all out! > > Greetings > > Mathias _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
