RFC: Saving and restoring the assembler state during assembly

[Dave Martin <dave dot martin at linaro dot org>]

Hi all,

On ARM, we've now hit the problem a few times of temporarily
overriding the assembler state (or rather, not being able to do this
reliably).  For example, sometimes there's a need to assemble a few
instructions for a different architecture version so we can optionally
execute or skip them at run-time is not really possible at present.
This sort of feature is especially useful in macros but can be useful
elsewhere too.

There seem to be some target-specific solutions to this problem
already.  MIPS has its "option stack", maintained by .set push and
.set pop directives.  From the documentation, it sounds like this
saves/restores a somewhat comprehensive set of state, but doesn't make
much syntactic sense on arches which use .set to define symbols (i.e.,
most arches).  PowerPC also has .machine push and .machine pop, but
those only act on one specific aspect of the assembler state, and
therefore aren't as portable a concept.

However, there's not really anything fundamentally
architecture-specific about this problem, and ideally the solution and
the directives should not be architecture-specific either.
One option which appeals to me is to have some directives which can
exist across all architectures, and do something analogous to what
.set push and ,set pop do on MIPS.

My names would be .pushenv and .popenv, but obviously, they can be
named any way people like.  (For now I'm stealing groff's
"environment" terminology to refer to such saved and restored state --
hence "env".  Again, the nomenclature is arbitrary.)

These directives would save and restore a target-specific set of
state, which the philosophy that anything that can reasonably be
changed with a directive mid-file can also be saved and restored with
.pushenv/.popenv.  Effectively, .popenv would be equivalent to issuing
the necessary set of assembler directives to restore the assembler
state to whatever it was at the last .pushenv (including the state of
the environment stack itself)

I feel that the environment should also include global,
target-independent state such as the current macro mode (.altmacro
versus .noaltmacro) and current ELF section stack state, but not
symbols or macro definitions themselves.  Currently, neither the macro
mode nor the behaviour of .previous is reliably restorable after being
changed (unless I missed something).  This can result in unexpected
behaviour after a macro which switches sections or changes the macro
mode.  This seems unfortunate since on most arches there is no
syntactic difference between a machine instruction and a macro
invocation -- hence in the presence of macros, the only time you're
really 100% certain what .previous will do is immediately after a
.pushsection or .section directive (which obviously is not much use).

Comments are welcome -- at the moment this is just a fuzzy idea for a
feature which might prove useful.

I haven't investigated the implementation implications -- maybe it
could be built straightforwardly around the current MIPS directives.

Cheers
---Dave