Re: Better handling of PIC suffixes in GAS expression parser

[Alexandre Oliva <aoliva at redhat dot com>]

On Apr  9, 2001, Alan Modra <alan@linuxcare.com.au> wrote:

>> I don't like changing hooks.

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

Ok, will do.

>> > 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.

Not only that.  My #definition of the hook also passes a pointer to
c.  Perhaps they should be passed as pointers from the caller of the
macro, instead of having the macro take the address of its arguments?

I don't think passing pointers to global data is evil.  It still lets
you make the global data static, and still lets you pass something
other than a particular global variable to the function.

>> 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.

Well, they'll at least need the enum and the pointer.  Considering
that the array has 4 pointers to symbols (regular, GOT, PLT and
GOTOFF), but that, in general, there will only be two variants of a
symbol (regular and one of GOT, PLT or GOTOFF), if you take into
account the overhead of a malloc() and the fact that you'd still be
adding a pointer to the array to each symbol, you'd probably not be
winning very much by keeping the array allocated separately from the
symbols.

> It depends on how big your struct is, and the percentage of symbols
> that will need to use the extra struct.

The struct is an enum and an array of 4 pointers to symbols per
symbol.  The alternative is an enum and a pointer per symbol, plus an
array per pair of symbols, on average.  Hmm...  Except that this
average assumes assembling PIC code.  When assembling non-PIC, the
extra space would be totally wasted.  Perhaps it's indeed a good idea
to keep the arrays separate.

> 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...

Local syms are not exempt from the extra fields.  They're often
referenced with @GOTOFF.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me