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:

> 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


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