[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

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

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

If to support that, you need to sprinkle “if (ctx.hasVerboseOption(“blah”))” in common code, then might as well make this available to all drivers that want it. I can see adding it to the darwin driver to help show what the linker is doing.

-Nick