[LLVMdev] [lld] driver and options questions

[Michael Spencer]

On Thu, Jan 24, 2013 at 3:52 PM, Nick Kledzik <kledzik at apple.com> wrote:
>
> On Jan 24, 2013, at 2:45 AM, Michael Spencer wrote:
>> On Wed, Jan 23, 2013 at 6:57 PM, Nick Kledzik <kledzik at apple.com> wrote:
>>> 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.
>>
>> Not allowing Drivers to touch anything except for core args has a very
>> important side effect. We will always be able to test everything
>> through -core and dump how to run it with -###. LLVM and Clang both
>> handle options like this, and it seems to scale fine.
>
> We can still test any option (for example a darwin specific option) like:
>     lld -flavor darwin -no_compact_unwind ...

The problem with this is that the driver is allowed to look at its
environment (the file system, environment vars, etc...) to figure
things out. -core isn't. It is only allowed to look at the command
line. For example, the line above would target whatever the default
target triple lld was configured for is.

>
> Clang is different than ld is that it currently (from my understand) just supports the gcc command line options.  It does not support completely different command line languages like binutils's ld and darwin's ld have.

Clang has many command line options that only effect a single
platform. Also, binutils-ld targets both Windows and Darwin in
addition to ELF systems.

>
> The darwin linker has ~100 command line options.  For most of those we will need to make up some core option name.  A name which no one will ever use, but exists solely go through a command line bottleneck.
>

Lots of these options probably have equivalents in other flavors. It's
also very easy to use TableGen to automatically forward a lot of these
options. This is what clang does for a large part of the -cc1 options.

> Looking forward to when lld is used as a library, I think we should have a (non-string based) programmatic interface. That is, some big (structured) struct with fields for all the linking configuration settings.  The linking is driven by this struct.  Then for command line links should  be layered on top of this.  That is, the driver's job should be to convert command line args into this big struct.  And, for debugging, the driver should have a way to take an instance of the big struct and dump it into command line args (like -###).

I agree. And this is a non-string based interface.

As for debugging, having -### give the -core command line is
important. It allows a dev to debug a crash on a totally unrelated
system to the user, as the entire context of the link (except the
individual files) is there on the command line.

>
> Given that model, the question is, is there one big struct that is the union of all options from all flavors?  Or a base struct and a subclass for each flavor.  I prefer the subclass per flavor approach.
>
> -Nick
>
>

Sub classing for each format would actually be fine. And would make it
easy to give unused argument errors for -core command lines that mix
flags.

- Michael Spencer