https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120301

            Bug ID: 120301
           Summary: RFE: context variables
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hpa at zytor dot com
  Target Milestone: ---

In the Linux kernel, we have a lot of functions which are annotated with
markings like __init to indicate a function that can be jettisoned after system
boot.

Given the compilation context, some of these definitions may be different, e.g.
inside a module versus not.

There are a number of cases where especially init code versus non-init code
have good reasons to behave differently. Notably, Linux contains a fairly
extensive self-patching framework, and the self-patching code is deeply
embedded in macros and inline functions. However, if included in an init
routine, the patching framework is useless -- it will not have executed by the
time the code runs, so invoking the patching framework is pure bloat. 

In that sense, it would be ideal to be able to query the compilation context.
In theory, this could be done by adding a constant variable definition to each
function, and have that variable passed along to inline functions via macros as
needed, but that has multiple problems:

1. It is syntactically extremely heavy, requiring lots of macros to implement
well.

2. As such a variable would have to be defined *inside* the function body
whereas __attribute__((section(""))) is defined *outside* the function body,
these would have to be kept manually in sync. It would also be required for
*every single function* in the code.

Simply querying the text section name (or section stem) is probably not
sufficient, as the lack of string handling in C would make it very difficult to
keep these as compile-time constants, without which it is pointless.

So I can see a couple of different variations, either of which would very
cleanly address this problem.

a. __builtin_section_p("string"): returns true iff the current text section is
"string" alt matches a fnmatch pattern "string".

b. __attribute__((sections ("string"))) and __builtin_sections_p("string"):
same idea, but "string" can now also be used as a stem for creating section
names. That way, a function in the, say, ".text.init" section can put its
static data in ".data.init" and ".rodata.init" without needing additional
annotations. This extends to things like function sections, cold text, and so
on. Reduces the need for an fnmatch pattern.

c. __attribute__((context (int))) and __builtin_context(): defines and returns
an integer value corresponding to the current compilation context (the context
specified for the currently generating non-inlined function; it should have the
same behavior - ignore or error - as sections specified on inline functions.)
Requires a second attribute to be added to the macros, but might be more
flexible.

If no context attribute is specified, __builtin_context() returns 0.

d. __attribute__((section[s] ("string", int))) - same concept as c, except that
the context identifier is added as an optional parameter to the section[s]
attribute.

Reply via email to