Skip to content

[clang] "modular_format" attribute for functions using format strings #147431

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 5 commits into
base: users/mysterymath/modular-printf/ir
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions clang/include/clang/Basic/Attr.td
Original file line number Diff line number Diff line change
Expand Up @@ -5223,3 +5223,14 @@ def NonString : InheritableAttr {
let Subjects = SubjectList<[Var, Field]>;
let Documentation = [NonStringDocs];
}

def ModularFormat : InheritableAttr {
let Spellings = [Clang<"modular_format">];
let Args = [
IdentifierArgument<"ModularImplFn">,
StringArgument<"ImplName">,
VariadicStringArgument<"Aspects">
];
let Subjects = SubjectList<[Function]>;
let Documentation = [ModularFormatDocs];
}
34 changes: 34 additions & 0 deletions clang/include/clang/Basic/AttrDocs.td
Original file line number Diff line number Diff line change
Expand Up @@ -9427,3 +9427,37 @@ silence diagnostics with code like:
__attribute__((nonstring)) char NotAStr[3] = "foo"; // Not diagnosed
}];
}

def ModularFormatDocs : Documentation {
let Category = DocCatFunction;
let Content = [{
The ``modular_format`` attribute can be applied to a function that bears the
``format`` attribute (or standard library functions) to indicate that the
implementation is modular on the format string argument. When the format string
for a given call is constant, the compiler may redirect the call to the symbol
given as the first argument to the attribute (the modular implementation
function).

The second argument is a implementation name, and the remaining arguments are
aspects of the format string for the compiler to report. If the compiler does
not understand an aspect, it must summarily report that the format string has
that aspect.

The compiler reports an aspect by issuing a relocation for the symbol
``<impl_name>_<aspect>``. This arranges for code and data needed to support the
aspect of the implementation to be brought into the link to satisfy weak
references in the modular implemenation function.

For example, say ``printf`` is annotated with
``modular_format(__modular_printf, __printf, float)``. Then, a call to
``printf(var, 42)`` would be untouched. A call to ``printf("%d", 42)`` would
become a call to ``__modular_printf`` with the same arguments, as would
Comment on lines +9453 to +9454
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So will any call to printf with a constant format specifier string be rewritten to call __modular_printf?

Also, who is responsible for writing these attributes? Are they only in the libc implementation, or can a user write one of these themselves on their own declarations? I'm asking because I wonder about compatibility; e.g., the call dispatches to __modular_printf but that doesn't know about some particular extension being used in the format specifier and so the code appears to misbehave.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So will any call to printf with a constant format specifier string be rewritten to call __modular_printf?

That's correct.

Also, who is responsible for writing these attributes? Are they only in the libc implementation, or can a user write one of these themselves on their own declarations? I'm asking because I wonder about compatibility; e.g., the call dispatches to __modular_printf but that doesn't know about some particular extension being used in the format specifier and so the code appears to misbehave.

Users could use these for their own implementations, in particular to allow functions that e.g. wrap vsnprintf to do logging etc. As for compatibility, if the compiler understands aspect names that the implementation doesn't, there's no issue, as the compiler will not spontaneously emit them if not requested. If an implementation requests a verdict on an implementation aspect unknown to the compiler, the compiler will conservatively report that the aspect is required. The modular_format attribute provided by the code and the aspect references emitted by the compiler thus form a sort of two-phase handshake between the code and compiler.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So will any call to printf with a constant format specifier string be rewritten to call __modular_printf?

That's correct.

Good to know, thanks!

Also, who is responsible for writing these attributes? Are they only in the libc implementation, or can a user write one of these themselves on their own declarations? I'm asking because I wonder about compatibility; e.g., the call dispatches to __modular_printf but that doesn't know about some particular extension being used in the format specifier and so the code appears to misbehave.

Users could use these for their own implementations, in particular to allow functions that e.g. wrap vsnprintf to do logging etc. As for compatibility, if the compiler understands aspect names that the implementation doesn't, there's no issue, as the compiler will not spontaneously emit them if not requested. If an implementation requests a verdict on an implementation aspect unknown to the compiler, the compiler will conservatively report that the aspect is required. The modular_format attribute provided by the code and the aspect references emitted by the compiler thus form a sort of two-phase handshake between the code and compiler.

My concern is more about dispatching in ways the user may not anticipate and getting observably different behavior. e.g., the user calls printf("%I64d", 0LL) and they were getting the MSVC CRT printf call which supported that modifier but now calls __modular_printf which doesn't know about the modifier. What happens in that kind of situation?

Copy link
Contributor Author

@mysterymath mysterymath Jul 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My concern is more about dispatching in ways the user may not anticipate and getting observably different behavior. e.g., the user calls printf("%I64d", 0LL) and they were getting the MSVC CRT printf call which supported that modifier but now calls __modular_printf which doesn't know about the modifier. What happens in that kind of situation?

Ah, if I understand what you're getting at, that can't happen: it's explicitly out of scope for the feature.

The modular_format attribute exists to advertise to compiler that is compiling calls to a function that the implementation can be split by redirecting calls and emitting relocs to various symbols. A header file is the only plausible mechanism to tell the compiler this, and that means that the header would need to be provided by and intrinsically tied to a specific version of the implementation. Otherwise, it would be impossible to determine what aspects the implementation requires to be emitted to function correctly.

Accordingly, this feature would primarily be useful for cases where libc is statically linked in and paired with its own headers. (llvm-libc, various embedded libcs, etc.) I suppose it's technically possible to break out printf implementation parts into a family of individual dynamic libraries, but even then, any libc header set that required that the libc implementation be dynamically replaceable would not be able to include modular_format.

So, for implementations that use this feature, printf and __modular_printf would always be designed together. To avoid ever introducing two full printf implementations into the link, printf would be a thin wrapper around __modular_printf that also requests every possible aspect of the implementation. This would mean that the two could never diverge.

As an aside, this is my first time landing a RFC across so many components of LLVM. I wasn't sure how much detail to include in each change; my intuition was to try to provide links to the RFC instead. I don't want the above reasoning to get buried, and it gives me pause that it wasn't readily accessible. But I'm also not entirely sure where it should live going forward. Advice would be appreciated.

``printf("%f", 42.0)``. The latter would be accompanied with a strong
relocation against the symbol ``__printf_float``, which would bring floating
point support for ``printf`` into the link.

The following aspects are currently supported:

- ``float``: The call has a floating point argument
}];
}
14 changes: 14 additions & 0 deletions clang/lib/CodeGen/CGCall.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -2560,6 +2560,20 @@ void CodeGenModule::ConstructAttributeList(StringRef Name,

if (TargetDecl->hasAttr<ArmLocallyStreamingAttr>())
FuncAttrs.addAttribute("aarch64_pstate_sm_body");

if (auto *ModularFormat = TargetDecl->getAttr<ModularFormatAttr>()) {
// TODO: Error checking
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a heck of a TODO :) Though, I'd expect us to do diagnostics during our normal checking of the format string, so we shouldn't really require anything here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hah, fair; this is very much a Draft PR. My intent was to get this in front of a bunch of eyes sooner rather than later, as this PR set touches everything every layer from the compiler through to libc (skipping the linker).

FormatAttr *Format = TargetDecl->getAttr<FormatAttr>();
StringRef Type = Format->getType()->getName();
std::string FormatIdx = std::to_string(Format->getFormatIdx());
std::string FirstArg = std::to_string(Format->getFirstArg());
SmallVector<StringRef> Args = {
Type, FormatIdx, FirstArg,
ModularFormat->getModularImplFn()->getName(),
ModularFormat->getImplName()};
llvm::append_range(Args, ModularFormat->aspects());
FuncAttrs.addAttribute("modular-format", llvm::join(Args, ","));
}
}

// Attach "no-builtins" attributes to:
Expand Down
27 changes: 27 additions & 0 deletions clang/lib/Sema/SemaDeclAttr.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -6745,6 +6745,29 @@ static void handleVTablePointerAuthentication(Sema &S, Decl *D,
CustomDiscriminationValue));
}

static void handleModularFormat(Sema &S, Decl *D, const ParsedAttr &AL) {
StringRef ImplName;
if (!S.checkStringLiteralArgumentAttr(AL, 1, ImplName))
return;
SmallVector<StringRef> Aspects;
for (unsigned I = 2, E = AL.getNumArgs(); I != E; ++I) {
StringRef Aspect;
if (!S.checkStringLiteralArgumentAttr(AL, I, Aspect))
return;
Aspects.push_back(Aspect);
}

// Store aspects sorted and without duplicates.
llvm::sort(Aspects);
Aspects.erase(llvm::unique(Aspects), Aspects.end());

// TODO: Type checking on identifier
// TODO: Merge attributes
D->addAttr(::new (S.Context) ModularFormatAttr(
S.Context, AL, AL.getArgAsIdent(0)->getIdentifierInfo(), ImplName,
Aspects.data(), Aspects.size()));
}

//===----------------------------------------------------------------------===//
// Top Level Sema Entry Points
//===----------------------------------------------------------------------===//
Expand Down Expand Up @@ -7669,6 +7692,10 @@ ProcessDeclAttribute(Sema &S, Scope *scope, Decl *D, const ParsedAttr &AL,
case ParsedAttr::AT_VTablePointerAuthentication:
handleVTablePointerAuthentication(S, D, AL);
break;

case ParsedAttr::AT_ModularFormat:
handleModularFormat(S, D, AL);
break;
}
}

Expand Down
Loading