On Mon, Jul 4, 2011 at 2:45 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Mon, 4 Jul 2011, Michael Hope wrote:
On Mon, Jun 20, 2011 at 4:15 PM, Michael Hope michael.hope@linaro.org wrote:
On Tue, Jun 14, 2011 at 9:03 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
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?
Hi Nicholas. Sorry for the delay. We'll talk about this at today's meeting and I'll follow up to this thread.
Hi Nicholas. We had a talk about it at the meeting (unfortunately) two weeks ago. The original request can be split into two bits: finding the current section name, and changing the assembler state at runtime.
The latter is possible but a fair chunk of work. Per section and per symbol attributes are possible but not implemented. One idea would be to add a new directive such as '.permitted push neon' to allow NEON instructions from here on, and '.permitted pop' to restore the previous state.
Sure, however that won't solve the problem at hand. From reading the minutes I have the impression ttwo issues might be mixed up together.
The section name work is trickier. I don't like Dave's suggestion of adding a new formal argument type which expands to the callers section
Well, it was a complete hack :)
name. It works, but isn't really a formal type like 'required' or 'vaargs'. An alternative is to add a new macro-local variable such as _sectionname.
That would certainly be perfectly fine.
Are we worried about polluting the macro parameter namespace? One intentional feature of my suggestion is that it cannot affect the behaviour of any existing code, albeit by a rather cumbersome means.
Another thing that concerns me is the suggestion of various different special-case tweaks to implement various instances of a general area of functionality.
In principle, it could be more efficient and robust to address the general case, i.e. how to save, restore and query an appropriate subset of the assembler state at run-time.
(Interestingly, troff -- which bears a surprisingly uncanny resemblance to an assembler -- seems to have better generic capabilities in this area despite its ancient lineage. Its environment and state variable concepts seem close to what seems to be needed here: environments allow clean restoration of state after temporary changes, and variables are available reflecting many aspects of the program's state at run-time. I'm not saying it's easy to flip a switch and integrate such capabilities into gas, but it's a more instructive comparison than you might initially think.)
Do you have a work around? How much smaller would the kernel be with support for fetching the current section name?
We do have a workaround which consists of pulling all the referenced code in the kernel and discarding it at run time instead of simply discarding it at link time. But this feels really awkward because the toolchain is really unhelpful here. The kernel size is not that huge considering that we're talking about some code marked as __exit i.e. module removal cleanup code which is obviously not needed when linking modules in the kernel. But with more runtime patching of the kernel techniques, more of that previously link-time discarded code now has to be moved to the __init section which could be seen as a regression.
I guess my main concern at this point is that this generates fragmentary mess in the kernel _source_, effectively breaking the kernel's own linking rules to deal with these special cases. Once there is mess, maintenance tends to make the mess worse over time even if no functionality is added. It would be much nicer if we could avoid the mess in the first place...
Cheers ---Dave