[llvm] [SystemZ][z/OS] Do not cache section definitions (PR #225157)

[MMS IT GmbH via llvm-commits]

mms-it-ch wrote:

A data point from porting Free Pascal to z/OS, where we carry a variant of this change (a unique key per call instead of removing the map; the effect on the sections should be the same):

Not reusing sections also splits the static initializer class. Every entry of `@llvm.global_ctors` / `@llvm.global_dtors` gets a part `.xtor` of its own in class `C_@@SQINIT`. Language Environment does not find the entries of a second part with the same name: a DLL with one constructor and one destructor branched to a wrong address in `cxxctor` (0C1) while it was loaded on z/OS 3.1. A C test shows the same at `-O0` (at `-O1` clang removed our trivial constructor, which hid the problem).

We now keep `C_@@SQINIT` and its parts shared (all entries in one part) and everything else uncached; with that, DLL loading works. The test we use:

```llvm
; RUN: llc < %s -mtriple=s390x-ibm-zos | FileCheck %s

; CHECK: C_@@SQINIT CATTR
; CHECK-NEXT: {{.*}}PART(.xtor)
; CHECK-NOT: PART(.xtor)

@llvm.global_ctors = appending global [1 x { i32, ptr, ptr }] [{ i32, ptr, ptr } { i32 65535, ptr @init, ptr null }]
@llvm.global_dtors = appending global [1 x { i32, ptr, ptr }] [{ i32, ptr, ptr } { i32 65535, ptr @fini, ptr null }]

define internal void @init() {
  ret void
}

define internal void @fini() {
  ret void
}
```

So if the PR goes forward in its current form, it would probably need the same exception for `C_@@SQINIT`. The approach suggested above (applying the logic only to the LSDA sections) would not touch `C_@@SQINIT`.

---
*Drafted with the help of Claude Code (Anthropic), in line with the LLVM AI Tool Use Policy. The DLL result above was observed on z/OS 3.1 with our variant of the change, not with this PR's branch.*


https://github.com/llvm/llvm-project/pull/225157