Better handling of PIC suffixes in GAS expression parser
Alexandre Oliva
aoliva@redhat.com
Mon Apr 9 04:01:00 GMT 2001
On Apr 9, 2001, Alan Modra <alan@linuxcare.com.au> wrote:
> 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.
I've been saying the enum has to be part of the symbol, not a separate
memory region.
> 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.
Sounds reasonable.
> md_parse_name would then just call make_expr_symbol after setting up the
> apropriate expression.
So that, for each occurrences of symbol@SUFFIX, we'd get a new expr
symbol. This seems far more wasteful than my proposal. But I like
the general approach. I'd just like some way to cache the variants of
a symbol so as to not have to create identical expr_symbols over and
over. I suppose I could still add the pointer to the array of
symbols, to cache the reloc expressions. How does that sound?
> expresssion evaluation and cleanup code should be taught to make use of
> X_add_number in an O_reloc expression too.
I'm afraid you're going somewhat beyond my current understanding of
the assembler here :-(
One more nit: won't make_expr_symbol() create a symbol that actually
takes up space in the final object?
--
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
More information about the Binutils
mailing list