================
@@ -6555,8 +6555,119 @@ 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. 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 (implicit specializations are
+diagnosed in each translation unit that instantiates them). 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.
+
+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 builds the module
+interface. Importing translation units do not re-emit the variable. A variable
----------------
tonykuttai wrote:
verified it. In a plain TU an inline variable is supported like any other
namespace-scope variable (`sccsid_inl` in the `CodeGen` test). Across a module
boundary, the module unit emits it even when it is unreferenced there (it goes
through the module-initializer list like the internal-linkage case), and an
importer that references it re-emits its own `linkonce_odr` copy as usual for
inline variables. That copy also carries the attribute, since it is serialized
with the declaration in the BMI, so the string is preserved whichever copy the
linker keeps. An importer that does not reference it emits nothing, and giving
the option to an importer never affects module-owned variables. Added test
cases to cover these.
https://github.com/llvm/llvm-project/pull/187986
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
