Re: Better handling of PIC suffixes in GAS expression parser

[Alan Modra <alan at linuxcare dot com dot au>]

On 9 Apr 2001, Alexandre Oliva wrote:

> On Apr  9, 2001, Alan Modra <alan@linuxcare.com.au> wrote:
> 
> > In thinking about the larger picture, I wonder if any of these special
> > symbol structs are really necessary?  Can't we think of the @GOT etc. as
> > being a special operator, define an O_reloc or some such operatorT, then
> > handle the whole show as a special expression.
> 
> Sounds reasonable.
> 
> > md_parse_name would then just call make_expr_symbol after setting up the
> > apropriate expression.
> 
> So that, for each occurrences of symbol@SUFFIX, we'd get a new expr
> symbol.

Thinking about it some more, no, you wouldn't.  I was wrong in saying
you'd need to call make_expr_symbol as md_parse_name returns an
expression, not a symbol.  The new O_reloc type expression node will be
able to represent symbol@SUFFIX +/- constant.  Don't try to handle
the +/- constant in md_parse_name, that belongs in expr.c:expr.

Hint for modifying existing code:  O_reloc is really a variation on
O_symbol, so code handling O_symbol should accept O_reloc too in most
cases.

>  This seems far more wasteful than my proposal.  But I like
> the general approach.  I'd just like some way to cache the variants of
> a symbol so as to not have to create identical expr_symbols over and
> over.  I suppose I could still add the pointer to the array of
> symbols, to cache the reloc expressions.  How does that sound?
> 
> > expresssion evaluation and cleanup code should be taught to make use of
> > X_add_number in an O_reloc expression too.
> 
> I'm afraid you're going somewhat beyond my current understanding of
> the assembler here :-(
> 
> One more nit: won't make_expr_symbol() create a symbol that actually
> takes up space in the final object?

No, expression symbols are only temporary, and must resolve to something
the object file format can handle.  They're not a real symbol, and IMO
should never have been kludged in as "symbols".

-- 
Alan Modra