This is the mail archive of the binutils@sources.redhat.com 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]

Re: Better handling of PIC suffixes in GAS expression parser


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 :-)

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

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

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?

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


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