This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Dealing with multiple gas versions

>>> On 12.10.11 at 10:15, Alan Modra <> wrote:
> On Wed, Oct 12, 2011 at 01:13:28AM -0400, Hans-Peter Nilsson wrote:
>> On Wed, 12 Oct 2011, Alan Modra wrote:
>> >  .ifndef __GAS_VERSION__
>> Before you carve that in stone, would it make sense to add a dot
>> in there to avoid any plausible clash with C macro/symbols?
>> Like __GAS.VERSION__ or something.
> I think we should be reasonably safe, and if we put a dot in the
> symbol name it just becomes another oddity you need to remember.

Actually I second Hans-Peter's concern. I would have recommended
something like @gasversion (with possibly the @ customizable by the
target) or .gasversion. (following the .startof. and .sizeof. special
operators), and would suggest using a consistent prefix/suffix on
eventual further such symbols to be introduced.

>> N.B. tc-cris.c:md_begin (BTW yes, I guess local symbols are
>> better).
> Hmm.  There is one problem in that local symbols get an error if you
> try to redefine them.  I reckon it would make sense to treat locals
> like symbols defined with .equ, ie. give them an implicit
> S_IS_VOLATILE.  Jan, do you remember why you chose to make local
> symbols error on redefining?

Because it's plain wrong to attempt to do so (since a reference to
such symbol would become ambiguous)? To me that's the major
difference between (traditional) equates and "normal" symbols.

Hence imo it might be better to create pre-defined symbols (this
and any possible future ones) as equates, so code already defining
the symbol (e.g. on the command line, from grep-ing "as --version"
output) wouldn't get confused.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]