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:
> 
> > On 9 Apr 2001, Alexandre Oliva wrote:
> >> +#ifdef md_parse_name_and_continuation
> >> +	  /* This is a hook for the backend to parse certain names
> >> +	     followed by suffixes. */
> >> +	  if (md_parse_name_and_continuation (name, c, input_line_pointer,
> >> +					      expressionP))
> >> +	    break;
> >> +#endif
> >> +
> >> #ifdef md_parse_name
> 
> > Rather than creating a new hook, why don't you make use of the existing
> > md_parse_name hook?
> 
> Basically, because:
> 
> > You'd need to modify it a little
> 
> I don't like changing hooks.  Better keep the old one, even if
> deprecated, and recommend ports to move on to the new one.  But I
> didn't know there were so few ports using the old hook.  I don't mind
> too much going over them and fixing them, but I generally prefer not
> to fix what ain't broken :-)

I think it worth the few changes you'd need to make, just so that we don't
have "old deprecated hooks" hanging around.

> > Also, input_line_pointer is a global, and probably will need to be
> > modified inside the md_.. function so there's not much point in passing it
> > as a parameter.
> 
> It's global today, but we don't have to treat it as such.  Globals are
> evil :-)
> 
> I'd rather pass all the state into the hook, so as to make as few
> assumptions as possible about global state in it.

But you will need to change the global value of input_pointer from within
the hook.  That means passing &input_pointer to the hook, which is really
just as "evil" as making use of the global directly.

> >> I set TC_SYMFIELD_TYPE and TC_LOCAL_SYMFIELD_TYPE to a struct
> >> sym_pic_notes, with an enum indicating whether the symbol is a regular
> >> symbol, a @GOT, @PLT or @GOTOFF reference, or _GLOBAL_OFFSET_TABLE_.
> 
> > It might make more sense to have TC_*_SYMFIELD_TYPE a pointer to your new
> > struct.  Regular symbols thus wouldn't need to carry the extra baggage.
> 
> Regular symbols have to have pointers to their @GOT, @PLT and @GOTOFF
> counterparts, so that we can locate the special symbols.  We can't add
> them to the symbol table, so we need pointers to them elsewhere.

What I meant was:  only regular symbols that have @GOT etc. relocations
will need the extra baggage.

> I don't have a strong feeling about keeping the array outside, but the
> enum must be associated with the symbol.  I'm not sure the additional
> memory management complications are worth the trouble.  Do you think so?

I'm not sure either.  It depends on how big your struct is, and the
percentage of symbols that will need to use the extra struct.  If the
percentage is high and the extra size low then any extra complexity
wouldn't make sense.  Considering the number of local syms generated by
compilers though, I suspect the optimisation will be worth doing, but
that's just a gut feeling...

-- 
Alan Modra