[PATCH] D115024: [ifs] Patch llvm-ifs to allow output multiple types of stub file at the same time

Petr Hosek via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Dec 4 23:11:59 PST 2021


phosek added a comment.

In D115024#3171119 <https://reviews.llvm.org/D115024#3171119>, @haowei wrote:

> In D115024#3169966 <https://reviews.llvm.org/D115024#3169966>, @mcgrathr wrote:
>
>> This feature seems like a good addition. I'm wondering about the interactions with other switches and if it might make sense to rearchitect some of the CLI API here for the more arcane corners.  Maybe it's already orthogonal enough, but I'm not sure.  I'm thinking in particular about the various --strip-* options.  Perhaps it's the case that all such variations apply only to text IFS output?  I'm also wondering if there might be use cases for multiple different kinds of IFS output (i.e. different sets of stripping / arch options).  Come to think of it, we could even have uses for multiple ELF stub outputs from the same IFS input with different switches (e.g. arch).  So perhaps it makes sense to go in a direction where each output file is separately described with both its format (IFS vs ELF) and its format options (stripping, arch, etc), and there can be any number of such output files in whatever combination.  I'm not sure exactly what a CLI syntax for that would look like.  Another possibility that might fit well for build system integration is to accept a complex output specification in JSON either as a command-line switch value or from a file.
>>
>> I suspect that even if we do want to pursue a fancier CLI API along those lines, this might be a reasonable incremental step in that direction.
>
> The --strip-* options only work when output is (has) IFS and have no effect on other type of outputs. The helper text has indicate these flags works on IFS output (only). I think this was specified in the original design doc as well.
>
> I agree it might be an opportunity to support multiple output, not just multiple types of output. My first thought is something like:
>
> `--output-elf='elfA.so,--target=x86_64-linux-gnu'` `--output-elf='elfB.so,--target=aarch64-fuchsia-unknown`
>
> Essentially, we want some kind of tuple for each output file so we can specify information like targets. But that also mean we need an overhaul of flags parsing as current `cl::opt` does not seem to support it.

Alternative would be to make `--target=` position significant; every time it's set, it affects the flags that follow. So your example would look like this:

  --target=x86_64-linux-gnu --output-elf=elfA.so --target=aarch64-fuchsia-unknown --output-elf=elfB.so

That matches some of the other tools like ld which have position significant flags like `-Bdynamic` and `-Bstatic`.

`cl::opt` wouldn't handle this, but I think `llvm-ifs` should switch to `OptTable` anyway, and it should be implementable with `OptTable` similarly to how lld does it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115024/new/

https://reviews.llvm.org/D115024



More information about the llvm-commits mailing list