[all-commits] [llvm/llvm-project] 33872f: [GOFF] Add writing of section symbols (#133799)

[Kai Nacke via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 33872f12187b352b63e1749652cb18e678fc4f29
      https://github.com/llvm/llvm-project/commit/33872f12187b352b63e1749652cb18e678fc4f29
  Author: Kai Nacke <kai.peter.nacke at ibm.com>
  Date:   2025-06-26 (Thu, 26 Jun 2025)

  Changed paths:
    M llvm/include/llvm/BinaryFormat/GOFF.h
    M llvm/include/llvm/CodeGen/TargetLoweringObjectFileImpl.h
    M llvm/include/llvm/MC/MCContext.h
    A llvm/include/llvm/MC/MCGOFFAttributes.h
    M llvm/include/llvm/MC/MCGOFFStreamer.h
    M llvm/include/llvm/MC/MCObjectFileInfo.h
    M llvm/include/llvm/MC/MCSectionGOFF.h
    M llvm/include/llvm/MC/MCSymbolGOFF.h
    M llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
    M llvm/lib/MC/CMakeLists.txt
    M llvm/lib/MC/GOFFObjectWriter.cpp
    M llvm/lib/MC/MCContext.cpp
    M llvm/lib/MC/MCGOFFStreamer.cpp
    M llvm/lib/MC/MCObjectFileInfo.cpp
    A llvm/lib/MC/MCSectionGOFF.cpp
    M llvm/lib/Target/SystemZ/SystemZAsmPrinter.cpp
    M llvm/test/CodeGen/SystemZ/zos-ada-relocations.ll
    M llvm/test/CodeGen/SystemZ/zos-intrinsics.ll
    M llvm/test/CodeGen/SystemZ/zos-landingpad.ll
    A llvm/test/CodeGen/SystemZ/zos-ppa1.ll
    M llvm/test/CodeGen/SystemZ/zos-ppa2.ll
    A llvm/test/CodeGen/SystemZ/zos-section-1.ll
    A llvm/test/CodeGen/SystemZ/zos-section-2.ll
    M llvm/test/CodeGen/SystemZ/zos-simple-test.ll
    M llvm/test/MC/GOFF/empty-goff.s
    R llvm/test/MC/GOFF/ppa1.ll

  Log Message:
  -----------
  [GOFF] Add writing of section symbols (#133799)

Unlike other formats, the GOFF object file format uses a 2 dimensional structure
to define the location of data. For example, the equivalent of the ELF .text
section is made up of a Section Definition (SD) and a class (Element Definition;
ED). The name of the SD symbol depends on the application, while the class has
the predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.

Data can be placed into this structure in 2 ways. First, the data (in a text
record) can be associated with an ED symbol. To refer to data, a Label
Definition (LD) is used to give an offset into the data a name. When binding,
the whole data is pulled into the resulting executable, and the addresses
given by the LD symbols are resolved.

The alternative is to use a Part Definition (PR). In this case, the data (in
a text record) is associated with the part. When binding, only the data of
referenced PRs is pulled into the resulting binary.

Both approaches are used. SD, ED, and PR elements are modeled by nested
MCSectionGOFF instances, while LD elements are associated with MCSymbolGOFF
instances.

At the binary level, a record called "External Symbol Definition" (ESD) is used. The
ESD has a type (SD, ED, PR, LD), and depending on the type a different subset of
the fields is used.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications