This is the mail archive of the 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]

Better handling of PIC suffixes in GAS expression parser

I dislike the way all implementations of PIC support that use @GOT,
@PLT, etc suffixes are implemented, in terms of parsing expressions
and choosing relocation types based on the suffixes found.

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.

Basically, in general, every time a PIC-aware assembler parses an
expression, it checks afterwards whether the expression (assumed to be
a single symbol) is followed by one of the magic suffixes, and then it
skips the suffix, reads the following expression, and goes from there.

I'd rather introduce hooks in the expression parser so that it would
be possible to have the generic parser handle PIC-aware expressions,
and then come up with a mechanism for the machine-specific code to
validate such expressions.

I see two options:

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

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

In the first case, we'd reject invalid expressions earlier, and the
rules to determine whether an expression is valid or not can be
defined in a single place.  Which means that, if different operands of
an insn have different rules, we may have to relax the rules and
fallback into the second situation, so one doesn't exclude the other.

I particularly like the idea of early validation and addition of hints
about the requested relocation types in expressions, but having
PIC-related pseudo-symbols created as local symbols appeals to me too.


Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                  aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
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]