[cfe-dev] Clang -Wa options (for integrated as)

[David Blaikie]

On Thu, Aug 21, 2014 at 7:37 AM, Renato Golin <renato.golin at linaro.org> wrote:
> Folks,
>
> Two bugs related -Wa option parsing in Clang that I could just easily
> add them one after the other, but I wanted to ask for your opinion
> first, as I don't even know where to start if not doing the obvious
> fix.
>
> http://llvm.org/bugs/show_bug.cgi?id=20339
> http://llvm.org/bugs/show_bug.cgi?id=20700
>
> These two bugs show that -Wa option doesn't accept much, and a look at
> the driver code show me that "static void
> CollectArgsForIntegratedAssembler()" is incomplete, to say the least.
>
> The questions that pop to mind are:
>
> 1. If I just want to add a new options to "allow" default behaviour to
> ignore its own flag (like -mimplitic-it=arm) and warn on improper use
> or missing features (like the work around for PR20700), would that be
> a good idea?

I think so (though I'm hardly the authority here, adding Chandler as
owner of the driver). That's what I did before I implemented
compression - support it in the driver, warn about it (either in the
driver or in -cc1as, I forget which). Then users with build systems
that try to compress debug info could simply disable the warning if
necessary, rather than having to have special build suport to
conditionally pass the flag only to the non-integrated linker (and the
warning would silently go away if they disabled the integrated
assembler, too, of course).

> 2. To implement -mfpu, I'd either have to re-use the current FPU
> parsing (which is not yet centralised), or I could leave that parsing
> to the underlying assembler. If that's so, do we try to validate here?
> Or do we ignore any unknown syntax and just hope the receiving end
> will validate and warn/error?

(I don't know enough about that stuff to have an opinion)

> 3. Clang basically ignores anything passed down to gas and only
> validates things for the integrated assembler, shouldn't we have
> similar behaviour and actually validate in our assembler?

Possibly - though of course our assembler has an API, not a command
line interface. Both -cc1 and -cc1as have to parse those options and
initialize the MCAssembler as appropriate, but we could factor that
into a common initialization and error handling down at that layer.

Not sure if that's the right refactoring (any such common handling is
just as easy (or easier) to do up in the driver - but, yeah, means one
fewer layer of explicit handling, potentially)

- David