[PATCH RFC 2/3] gas: add a means to programmatically determine the assembler version

[Jan Beulich]

On 11.12.2024 15:06, Michael Matz wrote:
> Hello,
> 
> On Mon, 9 Dec 2024, Jan Beulich wrote:
> 
>> It has been more than once that I would have wanted to have a way to
>> know the gas version in assembly sources, perhaps for use with .if. Add
>> such a pre-defined symbol, yet key exposure to -v being used at least
>> twice (three times to also emit the symbols to the symbol table).
> 
> Only defining the symbol with -vv or more is beyond quirky.  One would 
> never be able to rely on these symbols in .s sources then, possibly except 
> for test cases.  The common user wanting such symbol (for .if. or 
> otherwise, which is very reasonable!) wouldn't know that those .s files 
> need to be specifically assembled with -vv.  If the user learns of that, 
> then that prints the version, so the user then needs to know even more, 
> namely to use --silent.  Which then suppressed printing the version, but 
> _not_ the emission of the symbols.
> 
> That's not a sensible interface :-)
> 
> Just define the symbols always, the usage of non-symbol chars should make 
> all of this be reasonably non-conflicting with existing code.  If you 
> decide that you absolutely _must_ have a cmdline option to control this, 
> then don't make it be -v.  (I really think this should not depend on any 
> options!)

Hmm, maybe I was indeed overly concerned of still possible collisions with
what people might use. The advent of quoted symbol names, despite remaining
quirks there, has - after all - provided people with great freedom as to
the naming of their symbols.

> Suggestion: make the symbols for .if. usage that are predefined be of a 
> dependable format: e.g. 'GAS_DEFINED(foobar)' (where "foobar" would be the 
> different names, but the whole string, including parens is the symbol).
> That way the probability of conflicts with current code is about zero and 
> the symbol names are somewhat systematic.

I'll have to think about this. It surely has advantages over the initial
naming scheme I used; it merely feels as if this could also end up
misleading / ambiguous, but to support / discard that concern I'll need to
play some with it.

Jan