[PATCH] <<Proposed Driver Update>>

Nick Kledzik kledzik at apple.com
Mon Mar 4 13:40:48 PST 2013


On Mar 3, 2013, at 6:29 PM, Shankar Kalpathi Easwaran <shankarke at gmail.com> wrote:
>  Overall, I like the design so that the drivers are separate.
> 
>  Currently the LinkerOptions serves two purposes, that it contains Target specific options as well as  Core Linker options.
> 
>  I dont think Core linker options should be contained within the target, may lead to duplicated functionality, isnt it ?
Currently the "core" part of the linker just has a TargetInfo object with which to figure out settings.  The TargetInfo object has a getLinkerOptions() method with returns a reference to the LinkerOptions object.  So, for instance, the resolver has code like:

  if (_targetInfo.getLinkerOptions._globalsAreDeadStripRoots)

I think it would be simpler to have TargetInfo expose the LinkerOptions interface, so the above would become:

  if (_targetInfo.globalsAreDeadStripRoots())

It is simpler because:
1) It eliminates the LinkerOptions class by merging its functionality into the TargetInfo class. Currently the LinkerOptions and TargetInfo classes are always paired.  
2) Some of the LinkerOptions settings are "fixed" for a given subclass of TargetInfo.  That is, the LinkerOptions interface requires clients to set a bunch of fields on how to link (e.g. _searchArchivesToOverrideTentativeDefinitions) when the client really just wants to say "link like binutils does".  So routing the how-to-link questions through the TargetInfo object sets up the how-to-link settings correctly be default.

At first I was trying to mentally model LinkerOptions (and its subclasses) as "command line arguments", while TargetInfo (and its subclasses) are the things "always the same for a given platform, but might be different between platforms".   But after working through some code, I realized: a) there was no bright line.  Some things that seemed to be fixed for a platform turned out to have an obscure command line option to change it.  b) Once you are in XXXWriter and have an XXXTargetInfo object which can vend an XXXLinkerOptions object, it is arbitrary whether to put some configuration/option in XXXTargetInfo or in XXXLinkerOptions.  

I think the more important design issue is that we want to make it easy for clients (command line driver and programatic linking) to specify options and handle conflicts between options.  

-Nick






More information about the llvm-commits mailing list