33872f1218
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.
18 lines
499 B
LLVM
18 lines
499 B
LLVM
; A simple, barebones test to check whether assembly can be emitted
|
|
; for the z/OS target
|
|
; RUN: llc < %s -mtriple=s390x-ibm-zos | FileCheck %s
|
|
|
|
@a = global i32 0, align 4
|
|
|
|
define signext i32 @main() {
|
|
; CHECK: stdin#C CSECT
|
|
; CHECK: C_CODE64 CATTR ALIGN(3),FILL(0),READONLY,RMODE(64)
|
|
; CHECK: main:
|
|
; CHECK: stdin#C CSECT
|
|
; CHECK: C_WSA64 CATTR ALIGN(2),FILL(0),DEFLOAD,NOTEXECUTABLE,RMODE(64),PART(a)
|
|
; CHECK: a XATTR LINKAGE(XPLINK),REFERENCE(DATA),SCOPE(EXPORT)
|
|
; CHECK: a:
|
|
entry:
|
|
ret i32 0
|
|
}
|