================
@@ -6555,8 +6555,124 @@ When `#pragma comment(copyright, ...)` appears in a
C++20 module interface
unit, the copyright string is embedded only in the object file compiled from
that interface unit. Importing TUs do not re-emit the string.
-(langext-evaluating-object-size)=
+## Preserving Identifying Variables with -mloadtime-comment-vars
+
+The `-mloadtime-comment-vars=` flag accepts a comma-separated list of
+mangled variable names that should be preserved in the final object file as
+loadtime identifying strings. This is an AIX-specific feature; on other
+targets the compiler emits a warning. Names are matched against each
+variable's mangled name, and unrecognised names are silently ignored.
+
+This flag complements `#pragma comment(copyright, ...)` for codebases that
+already use the traditional UNIX convention of embedding identifying strings
+directly in source variables rather than via a pragma.
+
+Syntax:
+
+```console
+-mloadtime-comment-vars=<var1>[,<var2>,...]
+```
+
+In C, variable names are not mangled, so the mangled name is identical to the
source
+identifier (for example, `sccsid`). In C++, the mangled name follows the
+Itanium C++ ABI, so a namespace-scoped or internal-linkage variable (for
+example, a file-scope `static`) must be named using its mangled form:
+
+```c++
+namespace N { char sccsid[] = "@(#) MyApp Version 1.0"; } // N::sccsid ->
_ZN1N6sccsidE
+static char build[] = "@(#) Level 42"; // build ->
_ZL5build
+```
+
+```console
+-mloadtime-comment-vars=_ZN1N6sccsidE,_ZL5build
+```
+
+Valid variable types:
+
+A variable named in the list must meet all of these conditions to be
+preserved:
+
+- It must be defined at file or namespace scope; `inline`, `constexpr`, and
+ `constinit` variables are supported. A name-matched function-local `static`
+ variable, static data member, or variable template specialization is not
+ supported and is diagnosed.
+- Its type must be a character pointer (`char *`, `const char *`) or a
+ character array (`char[]`, `const char[]`). The character type must be plain
+ `char`: variables of `signed char`, `unsigned char`, and the wide and
+ Unicode character types (`wchar_t`, `char8_t`, `char16_t`, `char32_t`) are
+ not matched.
+- It must have static storage duration and must not be `volatile`-qualified.
+- It must be constant-initialized, so that the string is present in the object
+ at load time. A dynamically initialized variable (whose value is computed by
+ a start-up constructor) is not preserved.
+- A character *pointer* must be initialized directly with a string literal (for
+ example, `char *p = "@(#) ...";`). A pointer bound to some other object
+ -- even a constant one, such as another character array or the result of a
+ `constexpr` function returning the address of an external array -- does not
+ itself carry the identifying string and is not preserved. The expected
+ behavior is that the identifying string is present in the object file
+ compiled from the defining translation unit itself, not merely in the final
+ linked output.
+
+A variable that is named in the list but is `volatile`-qualified, does not
+have static storage duration (for example, a `thread_local` variable), is
+dynamically initialized, or is a pointer not bound to a string literal, is
+diagnosed with a warning and is not preserved. The same applies to name-matched
+variables of unsupported kinds: function-local `static` variables, static data
+members, and variable template specializations (an explicit specialization is
+diagnosed at its definition, an implicit one in each translation unit that
+instantiates it). A name-matched variable of any other type -- for example, an
+`int` or a `struct` -- is likewise diagnosed. A definition without an
+initializer is silently skipped. Names that match no variable defined in the
+translation unit are also silently ignored, since the option is typically
+given to every compilation of a build.
+
+For C++20 modules, a named variable defined in a module unit is processed when
+the module unit itself is compiled, and the option must be present on that
+compilation -- in a two-phase build, the step that produces the module
+interface file. Giving the option to an importing translation unit has no
+effect on variables owned by the module. An `inline` variable is preserved in
----------------
hubert-reinterpretcast wrote:
Before going into `inline` variable behavior, it is important to note that
retention to load time of the variable through use of the option is dependent
upon retention, by the linker, of function symbol definitions from translation
units that were compiled to preserve the variable.
https://github.com/llvm/llvm-project/pull/187986
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
