[LLVMdev] [lld] driver and options questions

Nick Kledzik
Thu, 24 Jan 2013 02:57:43 -0000

Michael,

I'm looking at flushing out the mach-o driver and targetinfo.

Can we rename the "ld64" flavor to "darwin".  The command
line tool on MacOSX is called "ld" - just like on unix.  The name ld64
is the current source repository name for the linker.  Once lld takes over,  the
term ld64 won't mean anything.

I've worked through adding DarwinOpts.td new DarwinDriver class, but have
some questions about wiring it up.  Currently the instantiated Driver transforms
the command line arguments in to "core" arguments which is passed to
generatedOptions() to construct a LinkerOptions object.

Is the plan for LinkerOptions to contain the superset of all flavor's
options?  That seems like it won't scale well.   In particular if you are
using lld as a library and you want to programmatically create a LinkerOptions,
it is unclear which options need to be set for a particular flavor.

It seems like the concrete subclass of TargetInfo will ultimately hold the
flavor specific options.  So can DarwinDriver get a copy of the MachOTargetInfo
object and set its ivars based on the command line options?   Previously, I
thought of LinkerOptions as the options needed by the core-linking phase
(resolver), and the WriterOptions were flavor specific.


Here is how I see it currently works:

1) The flavor determines the driver class instantiated.
2) The driver transforms flavor specific options into a "core"
ArgList;
3) LinkerOptions constructor requires a core ArgList and sets ivars base on the
ArgList.
4) The LinkerInvocation object is constructed from LinkerOptions object.
5) The LinkerInvocation object instantiates a Target object from the
LinkerOptions which also creates a TargetInfo object and passes ownership to of
the TargetInfo to the Target object.  This last step seems convoluted.
Couldn't the Target constructor create the TargetInfo ivar?
6) Problem: there is no way to connect flavor specific options to the
BlahTargetInfo object.



It seems like there are too many classes involved.  I think would be simpler to
have:
1) The flavor determines the Driver class instantiated.
2) The driver creates a TargetInfo subclass object.  The base class TargetInfo
contains all the fields that used to be in LinkerOptions.
3) The driver looks at each command line option and either uses it to set
something in the TargetInfo object or passes it to the super class to handle
TargetInfo base class options.
4) The LinkerInvocation object is constructed using the TargetInfo object.

In summary, my proposed model merges the Target class and LinkerOptions class
into the TargetInfo class.  The LinkerInvocation class runs a link based on a
TargetInfo object.  The TargetInfo object is programmatically configured.  In
the command line case, it is created by a Driver instance and configured based
on command line options.

If we really need all the classes, can you explain the purpose of each (in
doxygen comments).  Thanks.

-Nick