[Mesa-dev] [PATCH] radeon/llvm: Use LLVM C API for compiling LLVM IR to ISA.

[Mathias Fröhlich]

Hi,

On Wednesday, April 24, 2013 14:15:06 Tom Stellard wrote:
> I've thought about this some more, and I think that the best solution
> might be to move all LLVM API calls into gallivm and build it as a
> shared object with it's own private copy of LLVM statically linked.  This
> way we would still have a private copy of LLVM to work with, but without
> having to statically link every single gallium target with LLVM.  Any
> thoughts about this?
That should work as well.

As the test program shows, you would need to make sure that no llvm native api 
symbol is visible outside of this library. That means you baiscally have to 
build an own abstraction layer around llvm. Than you are safe for llvm at 
least.
More notes to that below.

> > For now, I have attached the patch series I mentioned regarding dlopen
> > flags which could be an other approach for this. I don't mind which
> > approach you really take in the end. Anyway this appears to work up to
> > now. It would have the advantage that it also helps other drivers beside
> > r600g with the llvm issues and it would help much further for all the non
> > static private symbols we have in the drivers. The series is running here
> > in my private tree since about half a year.
> 
> A few questions about the RTL_DEEPBIND patches:
> 
> 1. Does this only work for linux?
As far as I know yes.
At first even only glibc like targets.
So for android I don't know for example. And I don't have one available to 
look into at this moment.
Anyway, I think the desire to have a stronger seperation of dynamically loaded 
modules to be more independent of prebuilt binaries is there - especially on 
bsd license based userspaces. So I assume that you see more than just linux 
offering this or a similar flag. Sadly the times that I had access to all sorts 
of unices at work is gone.
So for example solaris10 has RTLD_GROUP which seems to be similar.

Which operating systems do we care for as of today? Is amds or intels list 
longer than the current list of systems for mesa?

> 2. Does RTL_DEEPBIND only make a difference if we are statically linking to
> LLVM?
As far as I understand this should also work for a shared llvm. You should 
really get an own instance of all the symbols in the shared object pulled by 
the .so you dlopen. This should include all statics and whatnot.

The limitation would be to make sure that the driver shared object finds the 
correct llvm libraries. In face of LD_LIBRARY_PATH or similar being set to 
something application defined you could still get the one provided by an 
application bringing its own one. This would still help for the thread safe 
initialization problem, but for this case you will never know which api 
version you are going to pull and if this might work.
But, if a (closed) application ships it's own llvm libraries - which is an 
appealing thought because of the still fast chaning llvm libraries - you can 
just run into this kind of problems with about any system library that pulls 
llvm under the hood. So this remaining problem is nothing we can really fix in 
mesa.
But you proposal with a libgalliumllvm abstraction helps for gallium based 
llvm clashes then, since the library file is called different than 
libllvmwhatevernativename.

In general, if you care for win32 targets with such a dynamic module 
structure, windows dynamic linking works somehow different than the linux one. 
But for this problem it's most notable that the default symbol visibility is 
set to hidden unless stated otherwise on win32. On *nix, you can see all 
symbols in a shared object unless explicitly marked hidden. So by default you 
get symbol clashes on *nix variants. But less of them on win32.
By your proposal with having a libgalliumllvm, statically linked with llvm and 
only exporting non llvm native symbol names you would have cought this problem 
already on win32.

Greetings

Mathias