On Mon, 4 Jul 2011, Michael Hope wrote:
> On Mon, Jun 20, 2011 at 4:15 PM, Michael Hope <michael.h...@linaro.org> wrote:
> > On Tue, Jun 14, 2011 at 9:03 AM, Nicolas Pitre <nicolas.pi...@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
> 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.
> 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.
Nicolas
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
