https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
Bug ID: 117265
Summary: RFE: extended asm support for assembly macros/assembly
headers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
There are things in assembly that is way easier to support using assembly
macros. Open-coding them in C may not even be possible, or at least is very
complex.
This includes, but is not limited to, such things as new instructions which
need to be hand-coded.
as also supports things like using registers or other non-constant as symbols,
which is sometimes *incredibly* useful.
The Linux kernel currently deals with this in what can at the very best be
called a hack: it includes the entire macro definition *at every single
callsite* and then uses .purgem afterwards. This has multiple issues:
1. Massive bloat.
2. Awkward for the programmer. This kind of code is already *very* hard to
write.
3. Duplicate definitions for inline asm and non-inline asm.
The easiest way to deal with this is probably to allow gcc to better support
assembly include files. This can currently sort-of be done with:
asm(".include \"filename\"");
... in global space, but there are a few serious problems there:
a. The filename will not be included in the dependencies output by the -M
series of options.
b. The include paths will not be searched, unless also specified with
-Wa,-I,path. However, this would have to be resolved in order to handle (a).
c. gcc does not guarantee that the .include statement will actually end up at
the beginning of the assembly file, before the call site. This is basically a
killer. For obvious reasons, we don't want to penalize the rest of the code
base by disabling optimizations.
(a) and (b) could be handled by a preprocessor function, e.g. _Filepath(string)
which would resolve to the path-searched filename as a quoted string and also
add it to the dependency list.
(c) would have to be addressed separately, and may very well have other
applications.
The alternative, less general but possibly simpler to implement, would be
something like an #asminclude directive.
