[LLVMdev] [lld] driver

[Michael Spencer]

On Thu, May 3, 2012 at 6:41 PM, Nick Kledzik <kledzik at apple.com> wrote:
> I'd like to do some more work on the darwin executable writer.  But most of the work is mach-o variations that are driven by command line options.  So I wanted to work out with you how command line processing will work.
>
> Looking at the Darwin man page for ld(1), it seems most options are darwin specific.  I image other platform linkers are similar.  So, to me it does not make sense to have one big interface that supports all options on all linkers.  Instead, Core just needs to model common options.  Then all platform specific options are a "private" interface within the platform.
>
> In other words, I see:
> 1) llvm/Support providing class to make command line parsing easy.
> 2) lld/Core providing utilities for managing search paths (for finding input files).
> 3) Each platform has its own main() which:
> 3a) uses the generic command line utilities to parse the options
> 3b) uses the options to set up the ResolverOptions
> 3c) calls Core/Resolver
> 3d) calls appropriate Passes (may depend on command line options)
> 3e) calls its platform executable writer, using private interface to specify platform specific options
>
>
> Thoughts?
>
> -Nick

The problem I see with this is embeddability and code duplication.
Programmatically setting up a link with common options for the target
platform should be trivial, this complicates that by requiring manual
setup of the process.

I was discussing this problem with Chandler, in addition to how to
share option parsing code with Clang. The general idea is to have a
tablegen file for canonical options (e.g. cc1 options in Clang). Then
each specific (ld64, gnu-ld, link.exe) driver would get a td file that
mapped each option to one or more canonical options either by a common
mapping operation, or calling a custom function.

- Michael Spencer