Better handling of PIC suffixes in GAS expression parser

[Alan Modra]

On 9 Apr 2001, Alexandre Oliva wrote:

> On Apr  9, 2001, Alan Modra <alan@linuxcare.com.au> wrote:
> 
> >> Well, they'll at least need the enum and the pointer.
> 
> > NULL pointer means something...  Which ought to remove the need for an
> > enum to just say "this is a symbol without fancy @GOT etc. relocations"
> 
> But then, as soon as the first @GOT relocation appears, the pointer
> will no longer be NULL, since it will have to start pointing at the
> array of fancy relocation symbols.  And then, we'll no longer be able
> to easily tell it's a regular symbol.  And, for the fancy ones, we'd
> have to store the suffix type somewhere.

Sorry, I wasn't very clear.  I meant that in the case where a symbol has
no @GOT relocations, you wouldn't need to set up a pointer to a little
struct with an enum saying "no @GOT relocations", which is what you seemed
to be saying.

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.  You could use X_op_symbol
to hold the relocation type;  A clean implementation would change
X_op_symbol to be

union {
  symbolS *s;
#ifdef BFD_ASSEMBLER
  enum bfd_reloc_code_real r;
#else
  int r;
#endif
}

md_parse_name would then just call make_expr_symbol after setting up the
apropriate expression.

  expressionS exp;
  exp.X_op = O_reloc;
  exp.X_add_symbol = symbol_on_lhs_of_@;
  exp.X_op_symbol.r = reloc_on_rhs_of_@;

expresssion evaluation and cleanup code should be taught to make use of
X_add_number in an O_reloc expression too.

-- 
Alan Modra