llvm dev - Sep 2013 - [LLVMdev] [lld][Options] Sharing common options across flavors

Hi Nick,

There are already a lot of options that are being shared across various 
flavors.  Adding a new option becomes a issue when that option need to 
available across all flavors.

As the first step, I am thinking of consolidating the common options 
shared across all the Unix variant flavors in CommonOptions.td.

The options that are shared between Darwin/GnuLD are :-

a) -o
b) -L
c) -emit-yaml
d) --help
e) -mllvm

I am also thinking of adding a verbose option that would essentially 
control the various verbose outputs that we might want to have. For example:

lld -flavor gnu -target x86_64 
--verbose=commandline,trampolines,symbols,reader,writer ....

LinkingContext will have two functions :-

setVerboseOptions(StringRef) -> stores all the verbose options in a vector.

hasVerboseOption(StringRef) -> returns true if the option is present

Thoughts on the above ?

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

On Sep 18, 2013, at 12:18 PM, Shankar Easwaran <shankare at
codeaurora.org> wrote:
> Hi Nick,
> 
> There are already a lot of options that are being shared across various
flavors.  Adding a new option becomes a issue when that option need to available
across all flavors.
> 
> As the first step, I am thinking of consolidating the common options shared
across all the Unix variant flavors in CommonOptions.td.
> 
> The options that are shared between Darwin/GnuLD are :-
> 
> a) -o
> b) -L
> c) -emit-yaml
> d) --help
> e) -mllvm
> 
That would make it difficult to use OptionGroup (as darwin driver has) so the
—help output is organized.  Also, the windows driver uses ‘/‘ so its entries use
F<> instead of Flag<>, so I not sure how you can factor these out. 
It also means that when looking at possible options, you’d have to look in two
files instead of one.

> I am also thinking of adding a verbose option that would essentially
control the various verbose outputs that we might want to have. For example:
> 
> lld -flavor gnu -target x86_64
--verbose=commandline,trampolines,symbols,reader,writer ....
> 
> LinkingContext will have two functions :-
> 
> setVerboseOptions(StringRef) -> stores all the verbose options in a
vector.
> 
> hasVerboseOption(StringRef) -> returns true if the option is present
> 
> Thoughts on the above ?
What do you mean by “verbose”.  Is this like DEBUG_WITH_TYPE()?  

-Nick

On 9/18/2013 4:31 PM, Nick Kledzik wrote:
> On Sep 18, 2013, at 12:18 PM, Shankar Easwaran <shankare at
codeaurora.org> wrote:
>
>> Hi Nick,
>>
>> There are already a lot of options that are being shared across various
flavors.  Adding a new option becomes a issue when that option need to available
across all flavors.
>>
>> As the first step, I am thinking of consolidating the common options
shared across all the Unix variant flavors in CommonOptions.td.
>>
>> The options that are shared between Darwin/GnuLD are :-
>>
>> a) -o
>> b) -L
>> c) -emit-yaml
>> d) --help
>> e) -mllvm
>>
> That would make it difficult to use OptionGroup (as darwin driver has) so
the —help output is organized.  Also, the windows driver uses ‘/‘ so its entries
use F<> instead of Flag<>, so I not sure how you can factor these
out.  It also means that when looking at possible options, you’d have to look in
two files instead of one.
Ah ok. I will leave it as is then.
>
>> I am also thinking of adding a verbose option that would essentially
control the various verbose outputs that we might want to have. For example:
>>
>> lld -flavor gnu -target x86_64
--verbose=commandline,trampolines,symbols,reader,writer ....
>>
>> LinkingContext will have two functions :-
>>
>> setVerboseOptions(StringRef) -> stores all the verbose options in a
vector.
>>
>> hasVerboseOption(StringRef) -> returns true if the option is present
>>
>> Thoughts on the above ?
> What do you mean by “verbose”.  Is this like DEBUG_WITH_TYPE()?
gnu ld has a verbose option that tells the user, whats going on in the 
linker from how it starts processing the command line to how symbols are 
being resolved.

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation