https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 
Uni-Bielefeld.DE> ---
> --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
>> --- Comment #12 from Petr Sumbera <sumbera at volny dot cz> ---
>> (In reply to Petr Sumbera from comment #9)
>>> (In reply to r...@cebitec.uni-bielefeld.de from comment #8)
>>> > > without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a 
>>> > > try
>>> > > until someone fixes and integrates SPARC JIT support for real.
>>> 
>>> I will try to build LLVM without the patch and will see. But the patch says
>>> it
>>> was created because of gnome-shell.
>>
>> When I updated test system with LLVM built without 033-solaris-LLVM-JIT.patch
>> (without rebuilding any other component) it fails in different way (probably
>> earlier). See bellow. I think that the patch is really needed.
> [...]
>> libLLVM-13.so`_ZN4llvm14RuntimeDyldELF23resolveX86_64RelocationERKNS_12SectionEntryEmmjlm+0x64(969a060b00?,
>> 9699f673c0?, 20?, 7af3bfb12000?, 18?, 0?)
>
> Seems so.  Calling llvm::RuntimeDyldELF::resolveX86_64Relocation on a
> SPARC ELF file is obviously complete bullshit.  Might be something
> already fixed in newer LLVM versions.  Somehow, the architecture
> detection is amiss...

That's almost certainly due to Solaris still including LLVM 13, which is
pretty old by now.  In particular, it lacks llvm::sys::getHostCPUName.
My patch to implement this on SPARC only landed in LLVM 16.

> However, given my impression from the mesa code is that even a proper
> error handling in RuntimeDyLD wouldn't help there.

Mesa uses the same function, so this may well be a second instance of
the same problem.

Reply via email to