Hello Michael,
We do have more and more instances of the following issues turning up in
the kernel requiring toolchain assistance to solve the problem properly.
Could you or someone from your team follow this up please?
-- Forwarded message --
Date: Tue, 1 Feb 2011 12:16:48 +
From: Dave Martin
To: binut...@sourceware.org
Cc: linaro-toolchain
Subject: Generating ancilliary sections with gas
Hi all,
Every now and again I come across a situation where it would be
really useful to be able to query the assembler state during
assembly: for example, to query and do something based on the
current section name. This makes it possible to write generic
macros to do certain things which otherwise require manual
maintenance, or complex and fragile external preprocessing.
Below, I give a real-world example of the problem, and sketch out
a possible solution.
What do people think of this approach? Does anyone have any better
ideas on how to solve this?
Cheers
---Dave
EXAMPLE
An example is the generation of custom ancilliary sections.
Suppose you want to write macros which record fixup information.
Currently, there's no way to put each fixup in an appropriately
named section automatically within gas. Tellingly, gas has had
to grow the ability to do this internally at least for ARM,
since the exception handling information in .ARM.ex{idx,tab}*
must go in sections with names based on the associated section
name. However, this ancillary section generation support is
neither flexible nor exposed to the user.
By putting fixups in sections whose names are based on the name
of the section they refer to, selective link-time discard of the
fixups (and hence the code referenced by the fixups) will work;
otherwise it doesn't. This would help avoid a situation where we
have to keep dead code in the kernel because custom fixups are
applied to it: at run-time, the code gets fixed up, then is
thrown away. The fixups can't be selectively discarded because
they are all in the same section: we seem have to no good
way to separate them out into separate sections appropriately.
For context, see:
http://www.spinics.net/lists/arm-kernel/msg112268.html
PROPOSAL
To solve the problem of generating custom ancillary sections
during assembly, here's a simple proposal: introducing a new kind of
macro argument can make aspects of the assembler state available to
macros in a flexible way, with only minimal implementation
required.
Basically, the macro qualifier field could be used to identify
arguments which are filled in by the assembler with information
about the assembly state, rather than being filled in by the
invoker of the macro: e.g.:
.macro mymacro name:req, flags, secname:current_section
/* ... */
.pushsection "\secname\name", "\flags"
/* ... */
.popsection
.endm
/* ... */
mymacro .ancillary, "a"
During expansion, \name and \flags are expanded as normal.
But \secname is substituted instead with the current section name,
so the macro expansion would look like this:
/* ... */
.pushsection ".text.ancillary", "a"
/* ... */
.popsection
Without the special :current_section argument, it doesn't appear
possible to implement a macro such as mymacro in a generic way.
This surely isn't the only way to achieve the goal, and it's
probably not the best way, but it does have some desirable
features.
Principally, while a new pseudo-op(s) could have been defined to
append text to the current section name, etc., allowing the current
section name to be appear as a macro parameter avoids prejudicing
the way the text is used. So there should never be a need to
introduce additional pseudo-ops to do things with the current
section name: with this patch, the user can always implement their
own macro to do the desired thing. This gets the desired
behaviour and maximum flexibility, while keeping the implementation
in gas very simple.
Also, using the macro expansion system in this way allows the
caller a free choice of macro parameter names, and so pretty much
guarantees that existing code won't get broken by the change.
Because my hack is currently simplistic, it has shortcomings: in
particular, it's not desirable to parse an argument from the
invocation line at all to fill a :current_section argument.
Currently, an argument is read in if present, but its value is
ignored and the current section name pasted in at macro expansion
time instead. However, that should be straightforward to fix with
a bit more code.
Of course, there's no reason only to expose the current section name
in this way. Any aspect of the the assembler state (current
subsection, current section flags, current instruction set, current
macro mode, etc.) could be made available in a similar way.
USAGE EXAMPLE AND PATCH
Note that the specific implementation described here is intended
to be illustrative, rather than complete or final.
binutils$ cat
