Re: CVS commit: src

[Jason Thorpe <thorpej%me.com@localhost>]

> On Jan 1, 2019, at 9:53 PM, maya%netbsd.org@localhost wrote:
> 
>> You're conflating two things that aren't related.  Mesa's use of LLVM is conceptually similar to the "Canadian cross", and at no point should the compiler run-times of the "build", "host", or "target" systems ever intermingle.
> 
> How come?
> 
> If an arrow means dynamic linking,
> 
> Octave -> Octave JIT -> LLVM 1
> |
> Mesa
> |
> LLVM 2
> 
> LLVM1 has someFunction(int x, int y)
> LLVM2 has someFunction(int x)

Yes, I see your point and it's clear that I misunderstood what you were saying.  But, the email I sent directly following addresses this situation.  My suggested solution would be:

Octave -> Octave JIT -> LLVM 1
|
Mesa
|
LLVM2-but-with-renamed-symbols-that-only-Mesa-knows, so you'd have:

LLVM1's someFunction(int x, int y)
...and...
LLVM2's __Mesa_Private_LLVM_someFunction(int x)

This could be done using the same mechanism by which we rename symbols in libc, or as a separate post-processing step similar to what librump does.

> I'm under the impression that, due to the flat namespace, whether a call
> to someFunction works correctly depends on which symbol is picked up
> first, LLVM1's or LLVM2's.
> 
> And, this applies to in-library calls in LLVM too.
> 
> This does seem to be the case. if I load a WebGL thing,
> 
>> pmap -p `pgrep firefox` |grep -i llvm
> 0000777D9FA00000  56024K read/exec         /usr/pkg/lib/libLLVM-7.so
> 0000777DA30B6000   2044K                   /usr/pkg/lib/libLLVM-7.so
> ..
> 
> Fortunately Firefox does not use LLVM twice in different ways, so
> failures don't happen.
> (Also the Octave scenario is not possible any more)

...also, it seems like the GNU-style symbol versioning support might be another way to solve this, yah?

-- thorpej