This is the mail archive of the
mailing list for the binutils project.
Re: Better handling of PIC suffixes in GAS expression parser
- To: Alexandre Oliva <aoliva at redhat dot com>
- Subject: Re: Better handling of PIC suffixes in GAS expression parser
- From: Nick Clifton <nickc at redhat dot com>
- Date: 17 Mar 2001 13:26:22 -0800
- Cc: binutils at sources dot redhat dot com
- References: <firstname.lastname@example.org>
> I'm willing to come up with a saner way to do it, but I'm first going
> to take a poll on which way people think would be best.
I have been trying to think of something useful to say, but since I
have not explored this code I am not familiar with the problems.
> - adding machine-specific fields to expressions (which is already
> possible), but introducing a mechanism for the machine-specific code
> to validate the combination of expressions, as well as determining how
> the additional fields should be set for the combined expression.
I like the sound of this method. It sounds reasonably generic, and
like something that could be extended to other, non-PIC related
> - generating PIC-related symbols as local symbols, adding
> machine-specific fields to them, and having validation done
> externally, after the full expression is parsed and constructed, when
> the relocation type is about to be chosen.
I am not so sure that I understand this. Are you suggesting that "@GOT"
would become a special local symbol ?