Skip to content
Open
Show file tree
Hide file tree
Changes from 4 commits
Commits
Show all changes
22 commits
Select commit Hold shift + click to select a range
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
5 changes: 4 additions & 1 deletion clang/lib/Driver/ToolChains/AIX.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -338,7 +338,10 @@ void aix::Linker::ConstructJob(Compilation &C, const JobAction &JA,
CmdArgs.push_back("-lpthread");
}
const char *Exec = Args.MakeArgString(ToolChain.GetLinkerPath());


// Required for 64-bit atomic operations used in sanitizer runtimes
// (e.g., sanitizer_common's atomic utilities). On 32-bit AIX, these
// are not natively supported, necessitating linkage with -latomic.
if (Sanitize.hasAnySanitizer() && IsArch32Bit) {
CmdArgs.push_back("-latomic");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please consider adding the code to clang::tools::driver::linkSanitizerRuntimeDeps (as was done for AIX sanitizer enablement in IBM's downstream) and adding the tests to clang/test/Driver/sanitizer-ld.c.

Copy link
Author

Choose a reason for hiding this comment

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

Thank you for the suggestion, @hubert-reinterpretcast. After careful consideration, I believe that keeping the -latomic handling directly in AIX.cpp is the more appropriate approach for the following reasons:

  1. Target-Specific Clarity:
    The logic for appending -latomic is very specific to the 32-bit AIX environment. By keeping it in AIX.cpp, we maintain a clear separation between platform-specific behavior and the more general sanitizer runtime dependency logic. This makes it immediately obvious to developers reviewing AIX-specific code that this flag is required solely for this target.

Copy link
Author

Choose a reason for hiding this comment

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

2. Consistency with Community LLVM Behavior:
Our implementation in AIX.cpp follows the established behavior in the LLVM community codebase. While IBM’s downstream has opted to centralize similar logic in clang::tools::driver::linkSanitizerRuntimeDeps, our approach isolates the AIX-specific behavior. This minimizes the risk of inadvertently impacting sanitizer handling on non-AIX targets.

Copy link
Author

Choose a reason for hiding this comment

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

3. Testing and Maintainability: The tests in clang/test/Driver/aix-ld.c are designed around this implementation. Moving the logic would complicate our test setup and risk unintended side effects.

Copy link
Author

Choose a reason for hiding this comment

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

while I appreciate the suggestion and understand the merits of aligning with IBM’s downstream practices, I believe that maintaining the target-specific logic in AIX.cpp is the best course for now. This decision is based on ensuring clarity, minimizing risk, and preserving consistency with the community’s expected behavior.

Please let me know if there are additional points to consider.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Please let me know if there are additional points to consider.

The addition of -latomic is not actually required even on AIX if the only sanitizer runtimes that are linked in are purely shared libraries.

The addition of -latomic for 32-bit AIX belongs in clang::tools::driver::linkSanitizerRuntimeDeps because the wider logic is already present to call that function only when sanitizer runtimes that contain static components are linked in.

See

bool NeedsSanitizerDeps = addSanitizerRuntimes(ToolChain, Args, CmdArgs);

if (NeedsSanitizerDeps)
linkSanitizerRuntimeDeps(ToolChain, Args, CmdArgs);

// C runtime, etc). Returns true if sanitizer system deps need to be linked in.
bool tools::addSanitizerRuntimes(const ToolChain &TC, const ArgList &Args,

return !StaticRuntimes.empty() || !NonWholeStaticRuntimes.empty();

Copy link
Collaborator

Choose a reason for hiding this comment

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

re: https://github.com/llvm/llvm-project/pull/125388/files#r1945365070:

By keeping it in AIX.cpp, we maintain a clear separation between platform-specific behavior and the more general sanitizer runtime dependency logic.

In this case, the actual result would have been unintentional platform-specific behaviour.

Copy link
Collaborator

@hubert-reinterpretcast hubert-reinterpretcast Feb 6, 2025

Choose a reason for hiding this comment

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

re: https://github.com/llvm/llvm-project/pull/125388/files#r1945365836:

Our implementation in AIX.cpp follows the established behavior in the LLVM community codebase.

Ignoring the lack of elaboration on how exactly placing this logic in AIX.cpp "follows the established behavior in the LLVM community codebase", the statement ignores the fact that the majority of linkSanitizerRuntimeDeps is code that is conditional based on platforms. For example:

if (TC.getTriple().isOSFreeBSD() || TC.getTriple().isOSNetBSD() ||
TC.getTriple().isOSOpenBSD() || TC.getTriple().isOSDragonFly())
CmdArgs.push_back("-lexecinfo");

While IBM’s downstream has opted to centralize similar logic in clang::tools::driver::linkSanitizerRuntimeDeps

The characterization that it is "IBM's downstream" that opted to centralize the logic in said function is misleading. The LLVM community had created said function for logic associated with linking in dependencies for static sanitizer components; IBM's downstream followed with that.

Copy link
Collaborator

@hubert-reinterpretcast hubert-reinterpretcast Feb 6, 2025

Choose a reason for hiding this comment

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

This minimizes the risk of inadvertently impacting sanitizer handling on non-AIX targets.

Generally, placing the code in a more widely used path will lead to more likely detection of problems. In other words, minimizing the risk of inadvertently impacting sanitizer handling on non-AIX targets increases the risk of having broken sanitizer handling on AIX. Considering that the risk of breaking non-AIX should be low (especially in an undetected manner) and that the risk of incorrect sanitizer handling on AIX is high during active development, I think deliberate attempts to isolate the AIX code (as opposed to using common code paths) is a mistake.

}
Expand Down
12 changes: 8 additions & 4 deletions clang/test/Driver/aix-ld.c
Original file line number Diff line number Diff line change
Expand Up @@ -1121,20 +1121,24 @@
// RUN: | FileCheck --check-prefixes=CHECK-K-UNUSED %s
// CHECK-K-UNUSED: clang: warning: -K: 'linker' input unused [-Wunused-command-line-argument]


// This check is only applicable to AIX targets.
// AIX-specific link behavior requires `-latomic` for 32-bit sanitizer libraries,
// Running this test on non-AIX targets will result in an unrelated error
Copy link
Collaborator

@hubert-reinterpretcast hubert-reinterpretcast Feb 3, 2025

Choose a reason for hiding this comment

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

I don't think that having this test (32-bit with no sanitizer) fail when using non-AIX environments/configurations is acceptable. This is basically the same as the first test in the file (CHECK-LD32). If this test is indeed failing, then please identify what the key difference is between this and the CHECK-LD32 test.

Additionally, "on non-AIX targets" is not correct. Is it "on non-AIX hosts" or "with non-AIX target configurations"?

// (e.g., missing atomic support on certain architectures),
// which is outside the scope of this bug and is addressed separately.

// Check No Sanitizer on 32-bit AIX
// RUN: %if target={{.*aix.*}} %{ \
// RUN: %clang -target powerpc-ibm-aix -m32 %s -### 2>&1 \
// RUN: | FileCheck -check-prefix=CHECK-LD32-NO-SANITIZER %s \
// RUN: %}
// %if target={{.*aix.*}} %{
// CHECK-LD32-NO-SANITIZER-NOT: "-latomic"
// %}

// Check enable AddressSanitizer on 32-bit AIX
// RUN: %if target={{.*aix.*}} %{ \
Copy link
Member

Choose a reason for hiding this comment

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

Where is this diagnostic Sanitizer interface functions must be exported by export files on AIX defined and why is there a host difference? I am concerned this would cause friction for people improve the generic interface to inadvertently cause regression on AIX, since most contributors don't have access to AIX.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Where is this diagnostic Sanitizer interface functions must be exported by export files on AIX defined and why is there a host difference?

It is strictly in IBM's downstream at this time. It will likely need revisiting before upstreaming. I have requested the removal of the driver part from this PR.

// RUN: %clang -target powerpc-ibm-aix -m32 -fsanitize=address %s -### 2>&1 \
// RUN: | FileCheck -check-prefix=CHECK-LD32-ASAN %s \
// RUN: %}
// %if target={{.*aix.*}} %{
// CHECK-LD32-ASAN: "-latomic"
// %}