[llvm-dev] TargetTriple issue: LC_VERSION_MIN_MACOSX: Darwin kernel version vs SDK version
Daniel Sanders via llvm-dev
llvm-dev at lists.llvm.org
Fri Sep 25 06:33:36 PDT 2015
(Re-added the list)
I don't know much about OSX so I'm not sure how much I can help with figuring out the fine detail. That said, I've noticed that AsmPrinter::doInitialization() is calling Triple::getOSVersion(). There's also a Triple::getMacOSXVersion() which claims to 'translate generic "darwin" versions to the corresponding OS X versions'. Could it be that AsmPrinter::doInitialization() should be calling getMacOSXVersion() for OSX?
From: Benoit Belley [mailto:Benoit.Belley at autodesk.com]
Sent: 25 September 2015 13:03
To: Daniel Sanders
Cc: Ian Ameline; Eric Bourque
Subject: Re: TargetTriple issue: LC_VERSION_MIN_MACOSX: Darwin kernel version vs SDK version
Hi Daniel,
We're using LLVM as a JIT compiler, no command-line. We would also prefer not hardcoding the Triple/TargetMachine at LLVM compile-time since that allows us to take full advantage of the user's machine capabilities at JIT time.
The workaround code shown below for setting up the Triple is used initialized the MCJIT engine and it works fine for now. This is not a blocking issue for us.
Still, there seems to be something fundamentally wrong in LLVM with the interpretation of the OS version on OS X. It doesn't differentiate correctly between the version of the Darwin Kernel and the version of the MacOS SDK.
I wouldn't mind help out cleaning that out. I just don't know what the appropriate fix might be. Here are a few options:
* The Triple should still store only the Darwin Kernel version
* And AsmPrinter.cpp should no longer write out the erroneous LC_VERSION_MIN_MACOSX tag. But, that feels like removing a feature...
* The Triple should store only the min MacOS SDK version instead of the Darwin Kernel version
* Any backward comp issues ? Is the Darwin Kernel version number used anywhere else ?
* The Triple should store both versions.
* But, it feels bad to have OS X specific stuff in the Triple. I mean OS X would have two versions to describe its OS environment. That sounds like the < Problem with the TargetTriple > discussion all over again.
* Pass the MinOS SDK requirements through some other mean...
Any suggestion ?
Cheers,
Benoit
From: Daniel Sanders <Daniel.Sanders at imgtec.com<mailto:Daniel.Sanders at imgtec.com>>
Date: vendredi 25 septembre 2015 05:55
To: Benoit Belley <benoit.belley at autodesk.com<mailto:benoit.belley at autodesk.com>>
Cc: Ian Ameline <Ian.Ameline at autodesk.com<mailto:Ian.Ameline at autodesk.com>>, Eric Bourque <Eric.Bourque at autodesk.com<mailto:Eric.Bourque at autodesk.com>>, "llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Subject: RE: TargetTriple issue: LC_VERSION_MIN_MACOSX: Darwin kernel version vs SDK version
Using 'clang -target ...-darwin10.10 ...' or configuring LLVM's default triple at configure-time (-DLLVM_DEFAULT_TARGET_TRIPLE=...-darwin10.10 for CMake) should work. I do the latter for MIPS32 toolchains on a MIPS64 host.
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Benoit Belley via llvm-dev
Sent: 24 September 2015 18:48
To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Cc: Ian Ameline; Eric Bourque
Subject: [llvm-dev] TargetTriple issue: LC_VERSION_MIN_MACOSX: Darwin kernel version vs SDK version
Hi everyone,
I just reported the following issue: https://llvm.org/bugs/show_bug.cgi?id=24927
Using the Xcode 7 linker, one gets messages such as the following when linking objects generated using llvm:
ld: warning: object file (foo.o) was built for newer OS X version (14.5) than being linked (10.9)
The issue is the following:
a) In lib/Support/Unix/Host.inc, sys::getDefaultTargetTriple() sets the OS name to darwin14.5 when running on MaxOS X 10.10. 14.5 is the Darwin kernel version as reported by uname.
b) In lib/CodeGen/AsmPrinter.cpp, AsmPrinter::doInitialization() writes out this version number to the LC_VERSION_MIN_MACOSX of the generated object.
c) The XCode 7 linker seems to expect that LC_VERSION_MIN_MACOSX contains the minimum version number of the MacOS X SDK (10.9, 10.11, ...), NOT the Darwin kernel version number!
AFAICT, LLVM had this wrong behaviour for a long time. The only new thing with Xcode 7 is that the linker is now reporting a warning for the version mismatch.
As a workaround, we are temporarily stripping out the darwin kernel version number from the triple in our project code. Something like:
// FIXME: LLVM confuses Darwin Kernel version numbers with MacOS X SDK
// version. By stripping out the kernel version number, we prevent the
// LC_VERSION_MIN_MACOSX directive from being emitted. Hopefully, that
// will get fixed by LLVM 3.8...
//
// See LLVM bug 24927: https://llvm.org/bugs/show_bug.cgi?id=24927#if defined(OSX)
#if (LLVM_VERSION_MAJOR < 3) || ((LLVM_VERSION_MAJOR == 3) && (LLVM_VERSION_MINOR < 8 ))
triple = Triple(triple.getArchName(),
triple.getVendorName(),
"darwin",
triple.getEnvironmentName());
#endif
#endif
This prevents the LC_VERSION_MIN_MACOSX directives from being emitted into the LLVM generated object files.
Any suggestions how to go about fixing LLVM to generate the correct LC_VERSION_MIN_MACOSX minimum SDK version number ? There seems to be no way to pass this information correctly through the Triple!
Thanks,
Benoit
Benoit Belley
Sr Principal Developer
M&E-Product Development Group
MAIN +1 514 393 1616
DIRECT +1 438 448 6304
FAX +1 514 393 0110
Twitter<http://twitter.com/autodesk>
Facebook<https://www.facebook.com/Autodesk>
Autodesk, Inc.
10 Duke Street
Montreal, Quebec, Canada H3C 2L7
www.autodesk.com<http://www.autodesk.com/>
[Description: Email_Signature_Logobar]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150925/79210168/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4316 bytes
Desc: image001.png
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150925/79210168/attachment-0001.png>
More information about the llvm-dev
mailing list