This is the mail archive of the
mailing list for the binutils project.
Re: RFC: Saving and restoring the assembler state during assembly
- From: Richard Sandiford <richard dot sandiford at linaro dot org>
- To: Dave Martin <dave dot martin at linaro dot org>
- Cc: binutils at sourceware dot org, linaro-toolchain <linaro-toolchain at lists dot linaro dot org>
- Date: Thu, 11 Aug 2011 16:22:24 +0100
- Subject: Re: RFC: Saving and restoring the assembler state during assembly
- References: <CA+wbFdek+ht9-odbRy+xurK4vomrUbAY7XnjmJc96XwhA3SFqQ__20916.email@example.com>
Dave Martin <firstname.lastname@example.org> writes:
> 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.
FWIW, this sounds like a really good idea to me. I won't argue about
the syntax (I have no particular preference).
> 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.
Sounds reasonable. To state the obvious, we'd have to make the existing
target-dependent groupings (like .set push/pop on MIPS) work with this
new scheme, but those directives musn't affect this extra target-independent
information. So the new directives would interact with both the
traditional .pushsection and the traditional target-dependent directives,
even though those two features would otherwise remain independent.
That is, .pushsection and .set push/pop operate on conceptually
separate stacks whoses pushes and pops can be freely mixed.
But .pushsection and the new directives would need to be
strictly stacked; pops must have the same form as their
corresponding pushes. Combinations of .set push/pop and
the new directives would also need to be strictly stacked.
Nothing a bit of code can't handle though.