[PATCH] Start fleshing out the Darwin driver

Nick Kledzik kledzik at apple.com
Sat Aug 24 08:46:04 PDT 2013


On Aug 23, 2013, at 10:55 PM, Joe Ranieri wrote:

> On Thu, Aug 22, 2013 at 3:43 PM, Nick Kledzik <kledzik at apple.com> wrote:
>> - How should the dylib compatibility and current version flags be stored? The minimum OS version is immediately validated outside of validateImpl and stored into a PackedVersion. There is no getter to access the exact value for that field, just the minOS helper.
> 
> The client of these version fields is the mach-o writer which needs the 32-bit value to place into the mach-o data structures.  Therefore, the value should be stored in the context as a 32-bit value (not as a string).   What this means is that the step that gets the -current_version arg needs to validate (can be parsed into packed 32-bit value) and report error if not (instead of doing the checking in validateImp).  The PackedVersion inner class should probably be removed and add utility methods  to the MachOLinkingContext class to convert uint32_t <-> StringRef.
> 
> I was going to argue that validateImpl cares about whether or not the string was specified or not, in order to issue the "you can't use current_version with bundles" error. However, it appears clangDriver actually takes care of issuing this error in 'darwin::Link::AddLinkArgs'.
> 
> Should lld error as well? Even though ld64 doesn't, it seems like lld should...
Think of validateImpl() as a check for the whole MachOLinkingContext which could have been created programmatically instead of through the driver. If the current_version in that struct is not the default value and the output type is not a dylib, then validateImpl() should warn/error that current_version won't be used.

In the Driver, the first thing it checks for is the output type, so when you get to -current_version farther down in the source, you can check if the output type is not a dylib and if not issue a warning/error.

-Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130824/3c7ef63b/attachment.html>


More information about the llvm-commits mailing list