[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-06-26 Thread Ulrich Weigand via llvm-branch-commits

https://github.com/uweigand approved this pull request.

This version looks good to me now, thanks!

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-06-25 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,106 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include 
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+  uint8_t FillByteValue = 0;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+  uint32_t SortKey = 0;
+};
+
+// Class names and other values depending on AMODE64 or AMODE31, and other
+// environment properties. For now, only the 64 bit XPLINK case is defined.
+
+// GOFF classes.
+constexpr StringLiteral CLASS_CODE = "C_CODE64";
+constexpr StringLiteral CLASS_WSA = "C_WSA64";
+constexpr StringLiteral CLASS_DATA = "C_DATA64";
+constexpr StringLiteral CLASS_PPA2 = "C_@@QPPA2";
+
+// Addres and residency mode.
+constexpr GOFF::ESDAmode AMODE = GOFF::ESD_AMODE_64;
+constexpr GOFF::ESDRmode RMODE = GOFF::ESD_RMODE_64;
+
+// Linkage.
+constexpr GOFF::ESDLinkageType LINKAGE = GOFF::ESD_LT_XPLink;
+
+// Loadding behavior.
+constexpr GOFF::ESDLoadingBehavior LOADBEHAVIOR = GOFF::ESD_LB_Initial;

uweigand wrote:

I'm wondering about the above four constants - it's a bit unclear how they will 
help (in the future) to possibly extend the implementation to 31-bit or 
non-XPLINK variants, since you'd have to get the mode input from somewhere.  
Also, these constants aren't used systematically, e.g. a few places use LINKAGE 
but others hard-coded ESD_LT_XPLink anyway.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-06-25 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;

uweigand wrote:

OK, thanks for checking.  Right now Amode is nowhere emitted to asm output at 
all anymore, but I guess that's because there is no asm output for LD symbols 
(function labels).   I assume this will be added later?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-06-25 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,106 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include 
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+  uint8_t FillByteValue = 0;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+  uint32_t SortKey = 0;
+};
+
+// Class names and other values depending on AMODE64 or AMODE31, and other
+// environment properties. For now, only the 64 bit XPLINK case is defined.
+
+// GOFF classes.
+constexpr StringLiteral CLASS_CODE = "C_CODE64";
+constexpr StringLiteral CLASS_WSA = "C_WSA64";
+constexpr StringLiteral CLASS_DATA = "C_DATA64";
+constexpr StringLiteral CLASS_PPA2 = "C_@@QPPA2";
+
+// Addres and residency mode.
+constexpr GOFF::ESDAmode AMODE = GOFF::ESD_AMODE_64;
+constexpr GOFF::ESDRmode RMODE = GOFF::ESD_RMODE_64;
+
+// Linkage.
+constexpr GOFF::ESDLinkageType LINKAGE = GOFF::ESD_LT_XPLink;
+
+// Loadding behavior.
+constexpr GOFF::ESDLoadingBehavior LOADBEHAVIOR = GOFF::ESD_LB_Initial;

redstar wrote:

My idea with the constants was to mark the places which needs to be changed for 
either 31 bit XPLINK or 31 bit StdLink. The root cause is that not all places 
need modifications, which may make it difficult to spot those places.
On the other hand, AMODE and RMODE are used systematically, but this means I 
can ditch them because every occurrence need to be changed.
The use is very limited right now, I'll remove them.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-06-25 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,106 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include 
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.

redstar wrote:

True, changed.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-06-24 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;

uweigand wrote:

Like above, right now there doesn't appear to be any code to emit LD symbols to 
asm output.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-06-24 Thread Ulrich Weigand via llvm-branch-commits

https://github.com/uweigand edited 
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-06-24 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,106 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include 
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.

uweigand wrote:

This comment doesn't match the current implementation any more.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-06-24 Thread Ulrich Weigand via llvm-branch-commits

https://github.com/uweigand commented:

Looks generally good to me now, still a few comments inline.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-06-16 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;

redstar wrote:

To confirm, setting the Amode is not necessary on PR symbols.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-05-06 Thread Fangrui Song via llvm-branch-commits

MaskRay wrote:

> @MaskRay Sorry, your comment is basically empty. I guess a GitHub problem?

Sorry... Could be my accidentally pushing a comment to a wrong PR.. 

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-05-06 Thread Kai Nacke via llvm-branch-commits

redstar wrote:

@MaskRay Sorry, your comment is basically empty. I guess a GitHub problem?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-05-02 Thread Fangrui Song via llvm-branch-commits

MaskRay wrote:

3





δΉ‹


https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-29 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;

redstar wrote:

I need to ask for this. I see only WXTRN for weak externals in the HLASM 
documentation.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-29 Thread Kai Nacke via llvm-branch-commits


@@ -223,13 +197,95 @@ void GOFFOstream::finalizeRecord() {
 }
 
 namespace {
+// A GOFFSymbol holds all the data required for writing an ESD record.
+class GOFFSymbol {
+public:
+  std::string Name;
+  uint32_t EsdId;
+  uint32_t ParentEsdId;
+  uint64_t Offset = 0; // Offset of the symbol into the section. LD only.
+   // Offset is only 32 bit, the larger type is used to
+   // enable error checking.
+  GOFF::ESDSymbolType SymbolType;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_ProgramManagementBinder;
+
+  GOFF::BehavioralAttributes BehavAttrs;
+  GOFF::SymbolFlags SymbolFlags;
+  uint32_t SortKey = 0;
+  uint32_t SectionLength = 0;
+  uint32_t ADAEsdId = 0;
+  uint32_t EASectionEDEsdId = 0;
+  uint32_t EASectionOffset = 0;
+  uint8_t FillByteValue = 0;
+
+  GOFFSymbol() : EsdId(0), ParentEsdId(0) {}
+
+  GOFFSymbol(StringRef Name, uint32_t EsdID, const GOFF::SDAttr &Attr)
+  : Name(Name.data(), Name.size()), EsdId(EsdID), ParentEsdId(0),
+SymbolType(GOFF::ESD_ST_SectionDefinition) {
+BehavAttrs.setTaskingBehavior(Attr.TaskingBehavior);
+BehavAttrs.setBindingScope(Attr.BindingScope);
+  }
+
+  GOFFSymbol(StringRef Name, uint32_t EsdID, uint32_t ParentEsdID,
+ const GOFF::EDAttr &Attr)
+  : Name(Name.data(), Name.size()), EsdId(EsdID), ParentEsdId(ParentEsdID),
+SymbolType(GOFF::ESD_ST_ElementDefinition) {
+this->NameSpace = Attr.NameSpace;
+// TODO Do we need/should set the "mangled" flag?
+SymbolFlags.setFillBytePresence(1);

redstar wrote:

That is a good point, because then we can also emit BSS data using the ORG 
instruction.
According to the AMBLIST output, the fill byte always ends up at the ED element.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-29 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_RMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_RMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_RMODE_None:
+  break;
+}
+if (UseParenthesis)
+  OS << ')';
+  }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+   bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+   GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+   GOFF::ESDLoadingBehavior LoadBehavior,
+   GOFF::ESDExecutable Executable, bool IsReadOnly,
+   StringRef PartName) {
+  if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_AMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_AMODE_ANY:
+  OS << "ANY";
+  break;
+case GOFF::ESD_AMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_AMODE_MIN:
+  OS << "ANY64";
+  break;
+case GOFF::ESD_AMODE_None:
+  break;
+}
+OS << "\n";
+  }
+  if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);
+OS << "\n";
+  }
+  OS << Name << " CATTR ";
+  OS << "ALIGN(" << static_cast(Alignment) << ")";
+  switch (LoadBehavior) {
+  case GOFF::ESD_LB_Deferred:
+OS << ",DEFLOAD";
+break;
+  case GOFF::ESD_LB_NoLoad:
+OS << ",NOLOAD";
+break;
+  default:
+break;
+  }
+  switch (Executable) {
+  case GOFF::ESD_EXE_CODE:
+OS << ",EXECUTABLE";
+break;
+  case GOFF::ESD_EXE_DATA:
+OS << ",NOTEXECUTABLE";
+break;
+  default:
+break;
+  }
+  if (IsReadOnly)
+OS << ",READONLY";
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << ',';
+emitRMode(OS, Rmode, /*UseParenthesis=*/true);
+  }
+  if (!PartName.empty())
+OS << ",PART(" << PartName << ")";
+  OS << '\n';
+}
+} // namespace
+
+void MCSectionGOFF::printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
+ raw_ostream &OS,
+ uint32_t Subsection) const {
+  switch (SymbolType) {
+  case GOFF::ESD_ST_SectionDefinition: {
+OS << Name << " CSECT\n";
+Emitted = true;
+break;
+  }
+  case GOFF::ESD_ST_ElementDefinition: {
+bool ParentEmitted = getParent()->Emitted;
+getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, Name, getParent()->getName(), !ParentEmitted,
+EDAttributes.Amode, EDAttributes.Rmode, EDAttributes.Alignment,
+EDAttributes.LoadBehavior, EDAttributes.Executable,
+EDAttributes.IsReadOnly, StringRef());
+  Emitted = true;
+} else
+  OS << Name << " CATTR ,\n";
+break;
+  }
+  case GOFF::ESD_ST_PartReference: {
+MCSectionGOFF *ED = getParent();
+bool SDEmitted = ED->getParent()->Emitted;
+ED->getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, ED->getName(), ED->getParent()->getName(), !SDEmitted,
+PRAttributes.Amode, getParent()->EDAttributes.Rmode,
+PRAttributes.Alignment, getParent()->EDAttributes.LoadBehavior,

redstar wrote:

IMHO there is no need to replicate the HLASM behaviour. The 
[table](https://www.ibm.com/docs/en/zos/3.1.0?topic=record-esd-item-behavioral-attribute-assignment)
 in the MVS Program Management: Advanced Facilities book clearly states that 
the LoadBehaviour and the Rmode are set at the ED.

Unfortunately, the attributes which can be set at the PR are in [another 
table](https://www.ibm.com/docs/en/zos/3.1.0?topic=record-external-symbol-definition-behavioral-attributes),
 inside the notes. This does not include LoadBehaviour and Rmode.

Over the first table there is a similar comment: "Note that the attributes of 
PR items (with the exception of alignment) are determined from the element EDID 
to which they belong." This seems to imply that those attributes set at the ED 
do not need to be set at the PR but I could not verify 

[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-29 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,106 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+  bool IsRenamable = false;
+  bool IsReadOnly = false; //  Not documented.

redstar wrote:

I checked again, and it seems we are only using the default value. I remove it.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-29 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,106 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+  bool IsRenamable = false;
+  bool IsReadOnly = false; //  Not documented.
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Byte;

redstar wrote:

The requirement for the alignment is that the aligment of ED must be equal or 
higher than the alignment of PR. However, to my knowledge it is not possible to 
share the ED element among several PR elements (because the SD must have the 
same name as the PR). Which means that both alignments are the same.
In HLASM, the alignment is given with the CATTR statement. If the CATTR defines 
no PART, then the alignment is set at the ED element, otherwise the same value 
is set at the ED and PR element.
I remove the alignment in the PR.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-25 Thread Ulrich Weigand via llvm-branch-commits


@@ -223,13 +197,95 @@ void GOFFOstream::finalizeRecord() {
 }
 
 namespace {
+// A GOFFSymbol holds all the data required for writing an ESD record.
+class GOFFSymbol {
+public:
+  std::string Name;
+  uint32_t EsdId;
+  uint32_t ParentEsdId;
+  uint64_t Offset = 0; // Offset of the symbol into the section. LD only.
+   // Offset is only 32 bit, the larger type is used to
+   // enable error checking.
+  GOFF::ESDSymbolType SymbolType;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_ProgramManagementBinder;
+
+  GOFF::BehavioralAttributes BehavAttrs;
+  GOFF::SymbolFlags SymbolFlags;
+  uint32_t SortKey = 0;
+  uint32_t SectionLength = 0;
+  uint32_t ADAEsdId = 0;
+  uint32_t EASectionEDEsdId = 0;
+  uint32_t EASectionOffset = 0;
+  uint8_t FillByteValue = 0;
+
+  GOFFSymbol() : EsdId(0), ParentEsdId(0) {}
+
+  GOFFSymbol(StringRef Name, uint32_t EsdID, const GOFF::SDAttr &Attr)
+  : Name(Name.data(), Name.size()), EsdId(EsdID), ParentEsdId(0),
+SymbolType(GOFF::ESD_ST_SectionDefinition) {
+BehavAttrs.setTaskingBehavior(Attr.TaskingBehavior);
+BehavAttrs.setBindingScope(Attr.BindingScope);
+  }
+
+  GOFFSymbol(StringRef Name, uint32_t EsdID, uint32_t ParentEsdID,
+ const GOFF::EDAttr &Attr)
+  : Name(Name.data(), Name.size()), EsdId(EsdID), ParentEsdId(ParentEsdID),
+SymbolType(GOFF::ESD_ST_ElementDefinition) {
+this->NameSpace = Attr.NameSpace;
+// TODO Do we need/should set the "mangled" flag?
+SymbolFlags.setFillBytePresence(1);

uweigand wrote:

Oh, and one more thing here: by hard-coding this here, we're not emitting any 
HLASM output.   Should we emit a CATTR FILL(0) then as well?   (But that's only 
supported on the PART apparently, while the fill byte is supposed to go on the 
ED?)

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-25 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,106 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+  bool IsRenamable = false;
+  bool IsReadOnly = false; //  Not documented.
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Byte;

uweigand wrote:

Same question for the alignment, can it ever differ from the ED alignment?   
How would you specify this in HLASM?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-25 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,106 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+  bool IsRenamable = false;
+  bool IsReadOnly = false; //  Not documented.

uweigand wrote:

Does it ever make sense for this value to differ from the ED value?  Or is this 
one of those attributes that should be copied from the element to the part?   
It doesn't seem possible to specific differing values in HLASM ...

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-25 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_RMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_RMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_RMODE_None:
+  break;
+}
+if (UseParenthesis)
+  OS << ')';
+  }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+   bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+   GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+   GOFF::ESDLoadingBehavior LoadBehavior,
+   GOFF::ESDExecutable Executable, bool IsReadOnly,
+   StringRef PartName) {
+  if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_AMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_AMODE_ANY:
+  OS << "ANY";
+  break;
+case GOFF::ESD_AMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_AMODE_MIN:
+  OS << "ANY64";
+  break;
+case GOFF::ESD_AMODE_None:
+  break;
+}
+OS << "\n";
+  }
+  if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);
+OS << "\n";
+  }
+  OS << Name << " CATTR ";
+  OS << "ALIGN(" << static_cast(Alignment) << ")";
+  switch (LoadBehavior) {
+  case GOFF::ESD_LB_Deferred:
+OS << ",DEFLOAD";
+break;
+  case GOFF::ESD_LB_NoLoad:
+OS << ",NOLOAD";
+break;
+  default:
+break;
+  }
+  switch (Executable) {
+  case GOFF::ESD_EXE_CODE:
+OS << ",EXECUTABLE";
+break;
+  case GOFF::ESD_EXE_DATA:
+OS << ",NOTEXECUTABLE";
+break;
+  default:
+break;
+  }
+  if (IsReadOnly)
+OS << ",READONLY";
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << ',';
+emitRMode(OS, Rmode, /*UseParenthesis=*/true);
+  }
+  if (!PartName.empty())
+OS << ",PART(" << PartName << ")";
+  OS << '\n';
+}
+} // namespace
+
+void MCSectionGOFF::printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
+ raw_ostream &OS,
+ uint32_t Subsection) const {
+  switch (SymbolType) {
+  case GOFF::ESD_ST_SectionDefinition: {
+OS << Name << " CSECT\n";
+Emitted = true;
+break;
+  }
+  case GOFF::ESD_ST_ElementDefinition: {
+bool ParentEmitted = getParent()->Emitted;
+getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, Name, getParent()->getName(), !ParentEmitted,
+EDAttributes.Amode, EDAttributes.Rmode, EDAttributes.Alignment,
+EDAttributes.LoadBehavior, EDAttributes.Executable,
+EDAttributes.IsReadOnly, StringRef());
+  Emitted = true;
+} else
+  OS << Name << " CATTR ,\n";
+break;
+  }
+  case GOFF::ESD_ST_PartReference: {
+MCSectionGOFF *ED = getParent();
+bool SDEmitted = ED->getParent()->Emitted;
+ED->getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, ED->getName(), ED->getParent()->getName(), !SDEmitted,
+PRAttributes.Amode, getParent()->EDAttributes.Rmode,
+PRAttributes.Alignment, getParent()->EDAttributes.LoadBehavior,

uweigand wrote:

The HLASM docs contain the somewhat cryptic statement: "Binding attributes 
assigned to the class are also assigned to the part." where is not really 
defined anywhere (I can see) what exactly "binding attributes" mean.

Do we need to replicate the HLASM behavior of setting Amode and LoadBehavior or 
not?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-25 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;

uweigand wrote:

I see.  This is not currently reflected in the HLASM output, however.  How 
would one do this?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-25 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;

uweigand wrote:

Just to double-check: your current code does *not* set Amode on the PR symbol.  
 Is is necessary to do this or not?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-23 Thread Kai Nacke via llvm-branch-commits

redstar wrote:

@uweigand I made all the suggested changes.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-21 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;

redstar wrote:

Well, while my statement is true it also means there is no way to refer to such 
data.
I checked, it's not required.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-17 Thread Fangrui Song via llvm-branch-commits

https://github.com/MaskRay commented:

LGTM. As I'm not familiar with z/OS, my review focused on its compatibility 
with the current MC infrastructure. (My internet access will be limited between 
April 20th and May 4th, which may cause delays in my response time.)

Thanks for reimplementing the getPPA1/PPA2 stuff that puzzled me :)

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits

https://github.com/redstar edited 
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,112 @@
+; RUN: llc <%s --mtriple s390x-ibm-zos --filetype=obj -o - | \

redstar wrote:

Moved the tests.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,141 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitCATTR(raw_ostream &OS, StringRef Name, GOFF::ESDRmode Rmode,

redstar wrote:

Remove the anonymous namespace, and added `static`.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits


@@ -26,6 +27,23 @@ GOFFObjectWriter &MCGOFFStreamer::getWriter() {
   return static_cast(getAssembler().getWriter());
 }
 
+namespace {
+// Make sure that all section are registered in the correct order.
+void registerSectionHierarchy(MCAssembler &Asm, MCSectionGOFF *Section) {

redstar wrote:

Remove the anonymous namespace, and added `static`.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits


@@ -26,6 +27,23 @@ GOFFObjectWriter &MCGOFFStreamer::getWriter() {
   return static_cast(getAssembler().getWriter());
 }
 
+namespace {
+// Make sure that all section are registered in the correct order.
+void registerSectionHierarchy(MCAssembler &Asm, MCSectionGOFF *Section) {

redstar wrote:

Remove the anonymous namespace, and added `static`.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits


@@ -599,8 +600,18 @@ class MCContext {
unsigned Flags,
unsigned EntrySize);
 
-  MCSectionGOFF *getGOFFSection(StringRef Section, SectionKind Kind,
-MCSection *Parent, uint32_t Subsection = 0);
+private:

redstar wrote:

Moved the code.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_RMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_RMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_RMODE_None:
+  break;
+}
+if (UseParenthesis)
+  OS << ')';
+  }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+   bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+   GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+   GOFF::ESDLoadingBehavior LoadBehavior,
+   GOFF::ESDExecutable Executable, bool IsReadOnly,
+   StringRef PartName) {
+  if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_AMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_AMODE_ANY:
+  OS << "ANY";
+  break;
+case GOFF::ESD_AMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_AMODE_MIN:
+  OS << "ANY64";
+  break;
+case GOFF::ESD_AMODE_None:
+  break;
+}
+OS << "\n";
+  }
+  if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);
+OS << "\n";
+  }
+  OS << Name << " CATTR ";
+  OS << "ALIGN(" << static_cast(Alignment) << ")";
+  switch (LoadBehavior) {
+  case GOFF::ESD_LB_Deferred:
+OS << ",DEFLOAD";
+break;
+  case GOFF::ESD_LB_NoLoad:
+OS << ",NOLOAD";
+break;
+  default:
+break;
+  }
+  switch (Executable) {
+  case GOFF::ESD_EXE_CODE:
+OS << ",EXECUTABLE";
+break;
+  case GOFF::ESD_EXE_DATA:
+OS << ",NOTEXECUTABLE";
+break;
+  default:
+break;
+  }
+  if (IsReadOnly)
+OS << ",READONLY";
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << ',';
+emitRMode(OS, Rmode, /*UseParenthesis=*/true);
+  }
+  if (!PartName.empty())
+OS << ",PART(" << PartName << ")";
+  OS << '\n';
+}
+} // namespace
+
+void MCSectionGOFF::printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
+ raw_ostream &OS,
+ uint32_t Subsection) const {
+  switch (SymbolType) {
+  case GOFF::ESD_ST_SectionDefinition: {
+OS << Name << " CSECT\n";
+Emitted = true;
+break;
+  }
+  case GOFF::ESD_ST_ElementDefinition: {
+bool ParentEmitted = getParent()->Emitted;
+getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, Name, getParent()->getName(), !ParentEmitted,
+EDAttributes.Amode, EDAttributes.Rmode, EDAttributes.Alignment,
+EDAttributes.LoadBehavior, EDAttributes.Executable,
+EDAttributes.IsReadOnly, StringRef());
+  Emitted = true;
+} else
+  OS << Name << " CATTR ,\n";
+break;
+  }
+  case GOFF::ESD_ST_PartReference: {
+MCSectionGOFF *ED = getParent();
+bool SDEmitted = ED->getParent()->Emitted;
+ED->getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, ED->getName(), ED->getParent()->getName(), !SDEmitted,
+PRAttributes.Amode, getParent()->EDAttributes.Rmode,
+PRAttributes.Alignment, getParent()->EDAttributes.LoadBehavior,

redstar wrote:

The HLASM statement
```
C_WSA64 CATTR ALIGN(4),DEFLOAD,NOTEXECUTABLE,RMODE(64),PART(a)
```
generates both the ED symbol `C_WSA64` and the PR symbol `a`.
At the ED symbol, Rmode and LoadBehaviour are set.
At the PR symbol, Amode (derived from RMode) and the LoadBehaviour are set. The 
latter looks like a HLASM bug. I am not aware of a way to defined the class 
(ED) and the part (PR) separately.


https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;

redstar wrote:

This is actually needed for C++ inline functions etc. which can end up in 
several object files. Also for weak definitions, e.g.:

```
// a.c
#include 

__attribute__((weak)) void fun() {
  printf("Weak fun\n");
}

void feature() {
  fun();
}
```
and
```
#include 

extern void feature();

void fun() {
  printf("Other fun\n");
}

int main(int argc, char *argv[]) {
  feature();
  return 0;
}
```
(example taken from a blog by @MaskRay)

Another case were the documentation needs an update.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Fangrui Song via llvm-branch-commits


@@ -0,0 +1,112 @@
+; RUN: llc <%s --mtriple s390x-ibm-zos --filetype=obj -o - | \

MaskRay wrote:

`llc < %s` does not need `-o -`. .ll tests in llvm/test/MC is probably not a 
good convention we'd recommend. Move to llvm/test/CodeGen/SystemZ, perhaps 
under a directory zos/ ?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Fangrui Song via llvm-branch-commits


@@ -599,8 +600,18 @@ class MCContext {
unsigned Flags,
unsigned EntrySize);
 
-  MCSectionGOFF *getGOFFSection(StringRef Section, SectionKind Kind,
-MCSection *Parent, uint32_t Subsection = 0);
+private:

MaskRay wrote:

instead of adding a `private`, just move the `getGOFFSection` to the existing 
private part.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_RMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_RMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_RMODE_None:
+  break;
+}
+if (UseParenthesis)
+  OS << ')';
+  }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+   bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+   GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+   GOFF::ESDLoadingBehavior LoadBehavior,
+   GOFF::ESDExecutable Executable, bool IsReadOnly,
+   StringRef PartName) {
+  if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";

redstar wrote:

>  I think we should actually emit the AMODE for that instead.
I (or Tony) will do when emitting the labels.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits

https://github.com/redstar edited 
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_RMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_RMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_RMODE_None:
+  break;
+}
+if (UseParenthesis)
+  OS << ')';
+  }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+   bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+   GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+   GOFF::ESDLoadingBehavior LoadBehavior,
+   GOFF::ESDExecutable Executable, bool IsReadOnly,
+   StringRef PartName) {
+  if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_AMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_AMODE_ANY:
+  OS << "ANY";
+  break;
+case GOFF::ESD_AMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_AMODE_MIN:
+  OS << "ANY64";
+  break;
+case GOFF::ESD_AMODE_None:
+  break;
+}
+OS << "\n";
+  }
+  if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);
+OS << "\n";
+  }
+  OS << Name << " CATTR ";
+  OS << "ALIGN(" << static_cast(Alignment) << ")";
+  switch (LoadBehavior) {
+  case GOFF::ESD_LB_Deferred:
+OS << ",DEFLOAD";
+break;
+  case GOFF::ESD_LB_NoLoad:
+OS << ",NOLOAD";
+break;
+  default:
+break;
+  }
+  switch (Executable) {
+  case GOFF::ESD_EXE_CODE:
+OS << ",EXECUTABLE";
+break;
+  case GOFF::ESD_EXE_DATA:
+OS << ",NOTEXECUTABLE";
+break;
+  default:
+break;
+  }
+  if (IsReadOnly)
+OS << ",READONLY";
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << ',';
+emitRMode(OS, Rmode, /*UseParenthesis=*/true);
+  }
+  if (!PartName.empty())
+OS << ",PART(" << PartName << ")";
+  OS << '\n';
+}
+} // namespace
+
+void MCSectionGOFF::printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
+ raw_ostream &OS,
+ uint32_t Subsection) const {
+  switch (SymbolType) {
+  case GOFF::ESD_ST_SectionDefinition: {
+OS << Name << " CSECT\n";
+Emitted = true;
+break;
+  }
+  case GOFF::ESD_ST_ElementDefinition: {
+bool ParentEmitted = getParent()->Emitted;
+getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, Name, getParent()->getName(), !ParentEmitted,
+EDAttributes.Amode, EDAttributes.Rmode, EDAttributes.Alignment,
+EDAttributes.LoadBehavior, EDAttributes.Executable,
+EDAttributes.IsReadOnly, StringRef());
+  Emitted = true;
+} else
+  OS << Name << " CATTR ,\n";
+break;
+  }
+  case GOFF::ESD_ST_PartReference: {
+MCSectionGOFF *ED = getParent();
+bool SDEmitted = ED->getParent()->Emitted;
+ED->getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, ED->getName(), ED->getParent()->getName(), !SDEmitted,
+PRAttributes.Amode, getParent()->EDAttributes.Rmode,
+PRAttributes.Alignment, getParent()->EDAttributes.LoadBehavior,
+PRAttributes.Executable, PRAttributes.IsReadOnly, Name);
+  ED->Emitted = true;
+  Emitted = true;
+} else
+  OS << ED->getName() << " CATTR ,\n";

redstar wrote:

My understaning is that it is sometimes done to get past the operand parsing in 
HLASM.
However, I just realized that the part name needs to be emitted, otherwise the 
CATTR statement produces an error.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_RMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_RMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_RMODE_None:
+  break;
+}
+if (UseParenthesis)
+  OS << ')';
+  }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+   bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+   GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+   GOFF::ESDLoadingBehavior LoadBehavior,
+   GOFF::ESDExecutable Executable, bool IsReadOnly,
+   StringRef PartName) {
+  if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_AMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_AMODE_ANY:
+  OS << "ANY";
+  break;
+case GOFF::ESD_AMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_AMODE_MIN:
+  OS << "ANY64";
+  break;
+case GOFF::ESD_AMODE_None:
+  break;
+}
+OS << "\n";
+  }
+  if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);
+OS << "\n";
+  }
+  OS << Name << " CATTR ";
+  OS << "ALIGN(" << static_cast(Alignment) << ")";
+  switch (LoadBehavior) {
+  case GOFF::ESD_LB_Deferred:
+OS << ",DEFLOAD";
+break;
+  case GOFF::ESD_LB_NoLoad:
+OS << ",NOLOAD";
+break;
+  default:
+break;
+  }
+  switch (Executable) {
+  case GOFF::ESD_EXE_CODE:
+OS << ",EXECUTABLE";
+break;
+  case GOFF::ESD_EXE_DATA:
+OS << ",NOTEXECUTABLE";
+break;
+  default:
+break;
+  }
+  if (IsReadOnly)
+OS << ",READONLY";
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << ',';
+emitRMode(OS, Rmode, /*UseParenthesis=*/true);
+  }
+  if (!PartName.empty())
+OS << ",PART(" << PartName << ")";
+  OS << '\n';
+}
+} // namespace
+
+void MCSectionGOFF::printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
+ raw_ostream &OS,
+ uint32_t Subsection) const {
+  switch (SymbolType) {
+  case GOFF::ESD_ST_SectionDefinition: {
+OS << Name << " CSECT\n";
+Emitted = true;
+break;
+  }
+  case GOFF::ESD_ST_ElementDefinition: {
+bool ParentEmitted = getParent()->Emitted;
+getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, Name, getParent()->getName(), !ParentEmitted,
+EDAttributes.Amode, EDAttributes.Rmode, EDAttributes.Alignment,
+EDAttributes.LoadBehavior, EDAttributes.Executable,
+EDAttributes.IsReadOnly, StringRef());
+  Emitted = true;
+} else
+  OS << Name << " CATTR ,\n";
+break;
+  }
+  case GOFF::ESD_ST_PartReference: {
+MCSectionGOFF *ED = getParent();
+bool SDEmitted = ED->getParent()->Emitted;
+ED->getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, ED->getName(), ED->getParent()->getName(), !SDEmitted,
+PRAttributes.Amode, getParent()->EDAttributes.Rmode,
+PRAttributes.Alignment, getParent()->EDAttributes.LoadBehavior,
+PRAttributes.Executable, PRAttributes.IsReadOnly, Name);

redstar wrote:

Yes, PRIORITY is needed.
I also emit the XATTR now. I emit REFERENCE(CODE/DATA), but I test if it is 
needed. It does not interact with CATTR [NON]EXECUTABLE but may interact with 
the EXECUTABLE/DATA property set at the external symbol referring to this part. 
In the past I got binder errors when when those were not matching but I have to 
check if this is true for PR symbols.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+  bool IsRenamable = false;
+  bool IsReadOnly = false; //  Not documented.
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+  GOFF::ESDDuplicateSymbolSeverity DuplicateSymbolSeverity =
+  GOFF::ESD_DSS_NoWarning;

redstar wrote:

On the other hand, this is the default value and we do not set it to a 
different value, thus we do not need to specify it.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-15 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+  bool IsRenamable = false;
+  bool IsReadOnly = false; //  Not documented.
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+  GOFF::ESDDuplicateSymbolSeverity DuplicateSymbolSeverity =
+  GOFF::ESD_DSS_NoWarning;

redstar wrote:

Me too. I need to ask someone with more HLASM knowledge.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-14 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+  bool IsRenamable = false;
+  bool IsReadOnly = false; //  Not documented.
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;

redstar wrote:

Removed.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-14 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_RMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_RMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_RMODE_None:
+  break;
+}
+if (UseParenthesis)
+  OS << ')';
+  }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+   bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+   GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+   GOFF::ESDLoadingBehavior LoadBehavior,
+   GOFF::ESDExecutable Executable, bool IsReadOnly,
+   StringRef PartName) {
+  if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_AMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_AMODE_ANY:
+  OS << "ANY";
+  break;
+case GOFF::ESD_AMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_AMODE_MIN:
+  OS << "ANY64";
+  break;
+case GOFF::ESD_AMODE_None:
+  break;
+}
+OS << "\n";
+  }
+  if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);

redstar wrote:

I changed it, only the `CATTR RMODE` is now emitted.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-14 Thread Kai Nacke via llvm-branch-commits


@@ -2759,6 +2762,29 @@ MCSection 
*TargetLoweringObjectFileXCOFF::getSectionForLSDA(
 
//===--===//
 TargetLoweringObjectFileGOFF::TargetLoweringObjectFileGOFF() = default;
 
+void TargetLoweringObjectFileGOFF::getModuleMetadata(Module &M) {
+  // Construct the default names for the root SD and the ADA PR symbol.
+  StringRef FileName = sys::path::stem(M.getSourceFileName());
+  if (FileName.size() > 1 && FileName.starts_with('<') &&
+  FileName.ends_with('>'))
+FileName = FileName.substr(1, FileName.size() - 2);
+  DefaultRootSDName = Twine(FileName).concat("#C").str();

redstar wrote:

Yes, my plan is to request an update to the documentation. 

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-14 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;

redstar wrote:

Ok, I removed this. However, it feels like that there is an inconsistency in 
the documentation / implementations. The following HLASM code
```
stdin#C CSECT
C_WSA64 CATTR ALIGN(4),DEFLOAD,NOTEXECUTABLE,PART(a),RMODE(64)
DC  0X
END
```
results in `RMODE(64)` set at the ED symbol, and `AMODE(64)` set at the PR 
symbol.
Setting the Amode on a PR symbol makes sense to me because it is not possible 
to add a LD symbol to the part - this is causing binder errors. To reference 
the part from a different compilation unit, I have to use `a`, thus the PR has 
also some symbol semantics. 

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-14 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;

redstar wrote:

No binding problems, so it seems sage to make this change. That said, amblist 
shows the Amode on PR and ED symbols.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-14 Thread via llvm-branch-commits


@@ -2759,6 +2762,29 @@ MCSection 
*TargetLoweringObjectFileXCOFF::getSectionForLSDA(
 
//===--===//
 TargetLoweringObjectFileGOFF::TargetLoweringObjectFileGOFF() = default;
 
+void TargetLoweringObjectFileGOFF::getModuleMetadata(Module &M) {
+  // Construct the default names for the root SD and the ADA PR symbol.
+  StringRef FileName = sys::path::stem(M.getSourceFileName());
+  if (FileName.size() > 1 && FileName.starts_with('<') &&
+  FileName.ends_with('>'))
+FileName = FileName.substr(1, FileName.size() - 2);
+  DefaultRootSDName = Twine(FileName).concat("#C").str();

AidoP wrote:

Thank you, that's very interesting. The documentation seems to suggest that the 
binding scope attribute only applies to LDs. Interestingly AMBLIST doesn't seem 
to display it (N/A is shown).

It seems like there are a few undocumented fields and behaviours being relied 
upon now. Is there anything being done or are there any plans for IBM to update 
the doc?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-14 Thread via llvm-branch-commits

https://github.com/AidoP edited https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-14 Thread via llvm-branch-commits

https://github.com/AidoP edited https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-14 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;

redstar wrote:

I had to do a bit of research here. The Amode at the ED symbol acts as a 
default when no Amode at the LD/ER is present. The Amode at the PR seems to be 
not necessary. However, I need to check if this results in binder errors if I 
remove this.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-11 Thread Kai Nacke via llvm-branch-commits


@@ -223,13 +197,95 @@ void GOFFOstream::finalizeRecord() {
 }
 
 namespace {
+// A GOFFSymbol holds all the data required for writing an ESD record.
+class GOFFSymbol {
+public:
+  std::string Name;
+  uint32_t EsdId;
+  uint32_t ParentEsdId;
+  uint64_t Offset = 0; // Offset of the symbol into the section. LD only.
+   // Offset is only 32 bit, the larger type is used to
+   // enable error checking.
+  GOFF::ESDSymbolType SymbolType;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_ProgramManagementBinder;
+
+  GOFF::BehavioralAttributes BehavAttrs;
+  GOFF::SymbolFlags SymbolFlags;
+  uint32_t SortKey = 0;
+  uint32_t SectionLength = 0;
+  uint32_t ADAEsdId = 0;
+  uint32_t EASectionEDEsdId = 0;
+  uint32_t EASectionOffset = 0;
+  uint8_t FillByteValue = 0;
+
+  GOFFSymbol() : EsdId(0), ParentEsdId(0) {}
+
+  GOFFSymbol(StringRef Name, uint32_t EsdID, const GOFF::SDAttr &Attr)
+  : Name(Name.data(), Name.size()), EsdId(EsdID), ParentEsdId(0),
+SymbolType(GOFF::ESD_ST_SectionDefinition) {
+BehavAttrs.setTaskingBehavior(Attr.TaskingBehavior);
+BehavAttrs.setBindingScope(Attr.BindingScope);
+  }
+
+  GOFFSymbol(StringRef Name, uint32_t EsdID, uint32_t ParentEsdID,
+ const GOFF::EDAttr &Attr)
+  : Name(Name.data(), Name.size()), EsdId(EsdID), ParentEsdId(ParentEsdID),
+SymbolType(GOFF::ESD_ST_ElementDefinition) {
+this->NameSpace = Attr.NameSpace;
+// TODO Do we need/should set the "mangled" flag?
+SymbolFlags.setFillBytePresence(1);

redstar wrote:

Only a result of using the default value, but I should be more explicit here.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-11 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+  bool IsRenamable = false;
+  bool IsReadOnly = false; //  Not documented.
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;

redstar wrote:

Removed.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-11 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;

redstar wrote:

Yes, that's true. I missed that somehow.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -599,8 +615,23 @@ class MCContext {
unsigned Flags,
unsigned EntrySize);
 
-  MCSectionGOFF *getGOFFSection(StringRef Section, SectionKind Kind,
-MCSection *Parent, uint32_t Subsection = 0);
+private:
+  MCSectionGOFF *getGOFFSection(SectionKind Kind,
+GOFF::ESDSymbolType SymbolType, StringRef Name,
+GOFF::SDAttr SDAttributes,
+GOFF::EDAttr EDAttributes,
+GOFF::PRAttr PRAttributes, MCSection *Parent);
+
+public:
+  MCSectionGOFF *getGOFFSection(SectionKind Kind, StringRef Name,
+GOFF::SDAttr SDAttributes,
+MCSection *Parent = nullptr);
+  MCSectionGOFF *getGOFFSection(SectionKind Kind, StringRef Name,
+GOFF::EDAttr EDAttributes,
+MCSection *Parent = nullptr);
+  MCSectionGOFF *getGOFFSection(SectionKind Kind, StringRef Name,
+GOFF::PRAttr PRAttributes,
+MCSection *Parent = nullptr);

uweigand wrote:

On the other hand, ED and PR must have a parent, so it shouldn't default to 
nullptr.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -239,6 +298,63 @@ class GOFFWriter {
 GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
 : OS(OS), Asm(Asm) {}
 
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+  if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+  Section.getSDAttributes());
+writeSymbol(SD);
+  }
+
+  if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
+  ED.SectionLength = Asm.getSectionAddressSize(Section);
+writeSymbol(ED);
+  }
+
+  if (Section.isPR()) {
+GOFFSymbol PR(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getPRAttributes());
+PR.SectionLength = Asm.getSectionAddressSize(Section);
+if (Section.requiresNonZeroLength()) {

uweigand wrote:

This is also unclear to me.   What are the actual rules?  Is is that PR 
sections of size zero are generally not allowed?  Then why do we need an extra 
flag here?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Kai Nacke via llvm-branch-commits


@@ -16,34 +16,95 @@
 #define LLVM_MC_MCSECTIONGOFF_H
 
 #include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/MC/MCGOFFAttributes.h"
 #include "llvm/MC/MCSection.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/raw_ostream.h"
 
 namespace llvm {
 
 class MCExpr;
 
 class MCSectionGOFF final : public MCSection {
-private:
-  MCSection *Parent;
-  uint32_t Subsection;
+  // Parent of this section. Implies that the parent is emitted first.
+  MCSectionGOFF *Parent;
+
+  // The attributes of the GOFF symbols.
+  GOFF::SDAttr SDAttributes;
+  GOFF::EDAttr EDAttributes;
+  GOFF::PRAttr PRAttributes;

redstar wrote:

Yes, I was thinking about that (but wanted to get everything to work first).

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -239,6 +298,63 @@ class GOFFWriter {
 GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
 : OS(OS), Asm(Asm) {}
 
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+  if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+  Section.getSDAttributes());
+writeSymbol(SD);
+  }
+
+  if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
+  ED.SectionLength = Asm.getSectionAddressSize(Section);
+writeSymbol(ED);
+  }
+
+  if (Section.isPR()) {
+GOFFSymbol PR(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getPRAttributes());
+PR.SectionLength = Asm.getSectionAddressSize(Section);
+if (Section.requiresNonZeroLength()) {

uweigand wrote:

But if you do call an external function, don't you then have to have actual 
data in the ADA identifying that external function?   I.e. don't those places 
that require a non-null ADA also automatically imply there are contents?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -230,10 +230,11 @@ class MCObjectFileInfo {
   MCSection *GLJMPSection = nullptr;
 
   // GOFF specific sections.
-  MCSection *PPA1Section = nullptr;
-  MCSection *PPA2Section = nullptr;
-  MCSection *PPA2ListSection = nullptr;
-  MCSection *ADASection = nullptr;
+  MCSection *RootSDSection = nullptr;

uweigand wrote:

Do we really need this, or could we use TextSection->getParent() when needed?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Kai Nacke via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;

redstar wrote:

There may be no LD. For example, the `B_IDRL` section has only SD and ED.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -239,6 +298,63 @@ class GOFFWriter {
 GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
 : OS(OS), Asm(Asm) {}
 
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+  if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+  Section.getSDAttributes());
+writeSymbol(SD);
+  }
+
+  if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
+  ED.SectionLength = Asm.getSectionAddressSize(Section);
+writeSymbol(ED);
+  }
+
+  if (Section.isPR()) {
+GOFFSymbol PR(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getPRAttributes());
+PR.SectionLength = Asm.getSectionAddressSize(Section);
+if (Section.requiresNonZeroLength()) {

uweigand wrote:

OK, thanks for following up on this.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_RMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_RMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_RMODE_None:
+  break;
+}
+if (UseParenthesis)
+  OS << ')';
+  }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+   bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+   GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+   GOFF::ESDLoadingBehavior LoadBehavior,
+   GOFF::ESDExecutable Executable, bool IsReadOnly,
+   StringRef PartName) {
+  if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_AMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_AMODE_ANY:
+  OS << "ANY";
+  break;
+case GOFF::ESD_AMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_AMODE_MIN:
+  OS << "ANY64";
+  break;
+case GOFF::ESD_AMODE_None:
+  break;
+}
+OS << "\n";
+  }
+  if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);

uweigand wrote:

The plain RMODE in GOFF mode HLASM also seems to be only for backward-compat 
purposes and sets the mode on an implicitly generated B_TEXT class.  I don't 
think we ever use that class at all - do we really want to set this?  We do 
need the "CATTR RMODE" which sets the mode on our actual class.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+  bool IsRenamable = false;
+  bool IsReadOnly = false; //  Not documented.
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;

uweigand wrote:

See above for the Amode comment.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;

uweigand wrote:

The whole Amode/Rmode handling is a bit confusing to me.  As I understand the 
GOFF docs, Amode is supposed to be a *symbol* property (i.e. set on LD and ER 
records) while Rmode is supposed to be an *element* property (i.e. set on ED 
records).   So it is unclear what an Amode property on ED or PR is supposed to 
do, exactly. There also doesn't seem to be a way to specify those with any 
HLASM command I can see.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;

uweigand wrote:

According to the GOFF docs, the NameSpace of LD or PR records must always match 
the NameSpace of the parent ED record.  If that's true, I don't think it is 
worthwhile allowing to specify this separately here.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_RMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_RMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_RMODE_None:
+  break;
+}
+if (UseParenthesis)
+  OS << ')';
+  }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+   bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+   GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+   GOFF::ESDLoadingBehavior LoadBehavior,
+   GOFF::ESDExecutable Executable, bool IsReadOnly,
+   StringRef PartName) {
+  if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_AMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_AMODE_ANY:
+  OS << "ANY";
+  break;
+case GOFF::ESD_AMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_AMODE_MIN:
+  OS << "ANY64";
+  break;
+case GOFF::ESD_AMODE_None:
+  break;
+}
+OS << "\n";
+  }
+  if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);
+OS << "\n";
+  }
+  OS << Name << " CATTR ";
+  OS << "ALIGN(" << static_cast(Alignment) << ")";
+  switch (LoadBehavior) {
+  case GOFF::ESD_LB_Deferred:
+OS << ",DEFLOAD";
+break;
+  case GOFF::ESD_LB_NoLoad:
+OS << ",NOLOAD";
+break;
+  default:
+break;
+  }
+  switch (Executable) {
+  case GOFF::ESD_EXE_CODE:
+OS << ",EXECUTABLE";
+break;
+  case GOFF::ESD_EXE_DATA:
+OS << ",NOTEXECUTABLE";
+break;
+  default:
+break;
+  }
+  if (IsReadOnly)
+OS << ",READONLY";
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << ',';
+emitRMode(OS, Rmode, /*UseParenthesis=*/true);
+  }
+  if (!PartName.empty())
+OS << ",PART(" << PartName << ")";
+  OS << '\n';
+}
+} // namespace
+
+void MCSectionGOFF::printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
+ raw_ostream &OS,
+ uint32_t Subsection) const {
+  switch (SymbolType) {
+  case GOFF::ESD_ST_SectionDefinition: {
+OS << Name << " CSECT\n";
+Emitted = true;
+break;
+  }
+  case GOFF::ESD_ST_ElementDefinition: {
+bool ParentEmitted = getParent()->Emitted;
+getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, Name, getParent()->getName(), !ParentEmitted,
+EDAttributes.Amode, EDAttributes.Rmode, EDAttributes.Alignment,
+EDAttributes.LoadBehavior, EDAttributes.Executable,
+EDAttributes.IsReadOnly, StringRef());
+  Emitted = true;
+} else
+  OS << Name << " CATTR ,\n";
+break;
+  }
+  case GOFF::ESD_ST_PartReference: {
+MCSectionGOFF *ED = getParent();
+bool SDEmitted = ED->getParent()->Emitted;
+ED->getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, ED->getName(), ED->getParent()->getName(), !SDEmitted,
+PRAttributes.Amode, getParent()->EDAttributes.Rmode,
+PRAttributes.Alignment, getParent()->EDAttributes.LoadBehavior,

uweigand wrote:

LoadBehavior and Rmode are only supported on ED, not PR.   Should we even emit 
those with the CATTR PART at all, or only with the base CATTR for the ED?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;

uweigand wrote:

According to the GOFF docs, while the executable flag is supported on ED, it's 
only purpose is to act as default for the executable flags in all LDs defined 
in this ED.   Assuming we set the flag in the LDs, do we also need it in the ED?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+  bool IsRenamable = false;
+  bool IsReadOnly = false; //  Not documented.
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+  GOFF::ESDDuplicateSymbolSeverity DuplicateSymbolSeverity =
+  GOFF::ESD_DSS_NoWarning;

uweigand wrote:

How would you set this via HLASM?  I wasn't able to find anything in the docs 
...

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_RMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_RMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_RMODE_None:
+  break;
+}
+if (UseParenthesis)
+  OS << ')';
+  }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+   bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+   GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+   GOFF::ESDLoadingBehavior LoadBehavior,
+   GOFF::ESDExecutable Executable, bool IsReadOnly,
+   StringRef PartName) {
+  if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";

uweigand wrote:

As above, reading the HLASM docs, the "AMODE" command in GOFF mode should refer 
to a *symbol* name, not a section name.   This may be a bit confusing due the 
section start symbol with the same name as the section - I think we should 
actually emit the AMODE for *that* instead.

(There is some HLASM backward compat mode for AMODE on a section name, but that 
also actually uses some implicitly generated section start symbol instead.)

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+  GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+  bool IsRenamable = false;
+  bool IsReadOnly = false; //  Not documented.
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;

uweigand wrote:

See above for the NameSpace comment.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_RMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_RMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_RMODE_None:
+  break;
+}
+if (UseParenthesis)
+  OS << ')';
+  }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+   bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+   GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+   GOFF::ESDLoadingBehavior LoadBehavior,
+   GOFF::ESDExecutable Executable, bool IsReadOnly,
+   StringRef PartName) {
+  if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_AMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_AMODE_ANY:
+  OS << "ANY";
+  break;
+case GOFF::ESD_AMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_AMODE_MIN:
+  OS << "ANY64";
+  break;
+case GOFF::ESD_AMODE_None:
+  break;
+}
+OS << "\n";
+  }
+  if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);
+OS << "\n";
+  }
+  OS << Name << " CATTR ";
+  OS << "ALIGN(" << static_cast(Alignment) << ")";
+  switch (LoadBehavior) {
+  case GOFF::ESD_LB_Deferred:
+OS << ",DEFLOAD";
+break;
+  case GOFF::ESD_LB_NoLoad:
+OS << ",NOLOAD";
+break;
+  default:
+break;
+  }
+  switch (Executable) {
+  case GOFF::ESD_EXE_CODE:
+OS << ",EXECUTABLE";
+break;
+  case GOFF::ESD_EXE_DATA:
+OS << ",NOTEXECUTABLE";
+break;
+  default:
+break;
+  }
+  if (IsReadOnly)
+OS << ",READONLY";
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << ',';
+emitRMode(OS, Rmode, /*UseParenthesis=*/true);
+  }
+  if (!PartName.empty())
+OS << ",PART(" << PartName << ")";
+  OS << '\n';
+}
+} // namespace
+
+void MCSectionGOFF::printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
+ raw_ostream &OS,
+ uint32_t Subsection) const {
+  switch (SymbolType) {
+  case GOFF::ESD_ST_SectionDefinition: {
+OS << Name << " CSECT\n";
+Emitted = true;
+break;
+  }
+  case GOFF::ESD_ST_ElementDefinition: {
+bool ParentEmitted = getParent()->Emitted;
+getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, Name, getParent()->getName(), !ParentEmitted,
+EDAttributes.Amode, EDAttributes.Rmode, EDAttributes.Alignment,
+EDAttributes.LoadBehavior, EDAttributes.Executable,
+EDAttributes.IsReadOnly, StringRef());
+  Emitted = true;
+} else
+  OS << Name << " CATTR ,\n";
+break;
+  }
+  case GOFF::ESD_ST_PartReference: {
+MCSectionGOFF *ED = getParent();
+bool SDEmitted = ED->getParent()->Emitted;
+ED->getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, ED->getName(), ED->getParent()->getName(), !SDEmitted,
+PRAttributes.Amode, getParent()->EDAttributes.Rmode,
+PRAttributes.Alignment, getParent()->EDAttributes.LoadBehavior,
+PRAttributes.Executable, PRAttributes.IsReadOnly, Name);

uweigand wrote:

Do we also need to set CATTR PRIORITY ?

There are some other PR properties that seem to require XATTR to be set via 
HLASM, in particular XATTR SCOPE, LINKAGE, and potentially 
REFERENCE(CODE/DATA).   (I'm not sure how the latter interacts with CATTR 
[NON]EXECUTABLE, however ... Also, the GOFF docs seem to imply that there is no 
executable property on PRs, but that may just be wrong ...)

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending 
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used 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, which means that the equivalent of a section in 
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+  GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+  GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+  bool IsReadOnly = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDAmode Amode;
+  GOFF::ESDRmode Rmode;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+  GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+  GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+  GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+  GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+  bool IsRenamable = false;
+  GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+  GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+  GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;

uweigand wrote:

For LD (as opposed to ER), it seems "strong" is the only allowed value here.  
Again, if this is true, it doesn't make much sense to specify it.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_RMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_RMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_RMODE_None:
+  break;
+}
+if (UseParenthesis)
+  OS << ')';
+  }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+   bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+   GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+   GOFF::ESDLoadingBehavior LoadBehavior,
+   GOFF::ESDExecutable Executable, bool IsReadOnly,
+   StringRef PartName) {
+  if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+  OS << "24";
+  break;
+case GOFF::ESD_AMODE_31:
+  OS << "31";
+  break;
+case GOFF::ESD_AMODE_ANY:
+  OS << "ANY";
+  break;
+case GOFF::ESD_AMODE_64:
+  OS << "64";
+  break;
+case GOFF::ESD_AMODE_MIN:
+  OS << "ANY64";
+  break;
+case GOFF::ESD_AMODE_None:
+  break;
+}
+OS << "\n";
+  }
+  if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);
+OS << "\n";
+  }
+  OS << Name << " CATTR ";
+  OS << "ALIGN(" << static_cast(Alignment) << ")";
+  switch (LoadBehavior) {
+  case GOFF::ESD_LB_Deferred:
+OS << ",DEFLOAD";
+break;
+  case GOFF::ESD_LB_NoLoad:
+OS << ",NOLOAD";
+break;
+  default:
+break;
+  }
+  switch (Executable) {
+  case GOFF::ESD_EXE_CODE:
+OS << ",EXECUTABLE";
+break;
+  case GOFF::ESD_EXE_DATA:
+OS << ",NOTEXECUTABLE";
+break;
+  default:
+break;
+  }
+  if (IsReadOnly)
+OS << ",READONLY";
+  if (Rmode != GOFF::ESD_RMODE_None) {
+OS << ',';
+emitRMode(OS, Rmode, /*UseParenthesis=*/true);
+  }
+  if (!PartName.empty())
+OS << ",PART(" << PartName << ")";
+  OS << '\n';
+}
+} // namespace
+
+void MCSectionGOFF::printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
+ raw_ostream &OS,
+ uint32_t Subsection) const {
+  switch (SymbolType) {
+  case GOFF::ESD_ST_SectionDefinition: {
+OS << Name << " CSECT\n";
+Emitted = true;
+break;
+  }
+  case GOFF::ESD_ST_ElementDefinition: {
+bool ParentEmitted = getParent()->Emitted;
+getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, Name, getParent()->getName(), !ParentEmitted,
+EDAttributes.Amode, EDAttributes.Rmode, EDAttributes.Alignment,
+EDAttributes.LoadBehavior, EDAttributes.Executable,
+EDAttributes.IsReadOnly, StringRef());
+  Emitted = true;
+} else
+  OS << Name << " CATTR ,\n";
+break;
+  }
+  case GOFF::ESD_ST_PartReference: {
+MCSectionGOFF *ED = getParent();
+bool SDEmitted = ED->getParent()->Emitted;
+ED->getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+  emitCATTR(OS, ED->getName(), ED->getParent()->getName(), !SDEmitted,
+PRAttributes.Amode, getParent()->EDAttributes.Rmode,
+PRAttributes.Alignment, getParent()->EDAttributes.LoadBehavior,
+PRAttributes.Executable, PRAttributes.IsReadOnly, Name);
+  ED->Emitted = true;
+  Emitted = true;
+} else
+  OS << ED->getName() << " CATTR ,\n";

uweigand wrote:

Why the comma at the end?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Kai Nacke via llvm-branch-commits


@@ -239,6 +298,63 @@ class GOFFWriter {
 GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
 : OS(OS), Asm(Asm) {}
 
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+  if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+  Section.getSDAttributes());
+writeSymbol(SD);
+  }
+
+  if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
+  ED.SectionLength = Asm.getSectionAddressSize(Section);
+writeSymbol(ED);
+  }
+
+  if (Section.isPR()) {
+GOFFSymbol PR(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getPRAttributes());
+PR.SectionLength = Asm.getSectionAddressSize(Section);
+if (Section.requiresNonZeroLength()) {

redstar wrote:

> That is a simple solution, too. I am not sure if this works with the HLASM 
> output.

Ok, I contradict myself. Setting the ADA to null gets around the binder error 
but other parts assume that there is always an ADA. E.g. when calling an 
external functions.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Ulrich Weigand via llvm-branch-commits


@@ -16,6 +16,9 @@ namespace llvm {
 class GOFFObjectWriter;
 
 class MCGOFFStreamer : public MCObjectStreamer {
+  std::string RootSDName;
+  std::string ADAPRName;

uweigand wrote:

These are no longer used, I think.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-10 Thread Kai Nacke via llvm-branch-commits


@@ -2759,6 +2762,29 @@ MCSection 
*TargetLoweringObjectFileXCOFF::getSectionForLSDA(
 
//===--===//
 TargetLoweringObjectFileGOFF::TargetLoweringObjectFileGOFF() = default;
 
+void TargetLoweringObjectFileGOFF::getModuleMetadata(Module &M) {
+  // Construct the default names for the root SD and the ADA PR symbol.
+  StringRef FileName = sys::path::stem(M.getSourceFileName());
+  if (FileName.size() > 1 && FileName.starts_with('<') &&
+  FileName.ends_with('>'))
+FileName = FileName.substr(1, FileName.size() - 2);
+  DefaultRootSDName = Twine(FileName).concat("#C").str();

redstar wrote:

Using a name and setting the binding scope to "section scope" is similar to 
using " " as name and leaving the binding scope unspecified.
The XLC and Open XL compilers provide a command line option to change this name 
(XLC: `-qcsect`, `-qnocsect`; Open XL: `-mcsect`, `-mnocsect`). The Open XL 
compiler defaults to the variant coded here but that can be changed to having a 
name with binding scope unspecified (`-mcsect=a`) or set to space (`-mnocsect`).
Using `-mcsect=a` results in exactly the problem you describe.
The compiler option will be added later to clang, along with the required code 
here.

The front end (aka clang) provides this value in the `source_filename` 
property. All strings in LLVM/clang are in UTF-8 so there is no other choice. 
The same problem arises for symbols derived from function names etc.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-09 Thread Ulrich Weigand via llvm-branch-commits


@@ -230,10 +230,11 @@ class MCObjectFileInfo {
   MCSection *GLJMPSection = nullptr;
 
   // GOFF specific sections.
-  MCSection *PPA1Section = nullptr;
-  MCSection *PPA2Section = nullptr;
-  MCSection *PPA2ListSection = nullptr;
-  MCSection *ADASection = nullptr;
+  MCSection *RootSDSection = nullptr;
+  MCSection *PPA2ListEDSection = nullptr;
+  MCSection *PPA2ListPRSection = nullptr;
+  MCSection *ADAEDSection = nullptr;
+  MCSection *ADAPRSection = nullptr;

uweigand wrote:

I don't think we really need two pointers each here.  Just the main section 
(i.e. the one where code is emitted to) should be enough, shouldn't it?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-09 Thread via llvm-branch-commits


@@ -2759,6 +2762,29 @@ MCSection 
*TargetLoweringObjectFileXCOFF::getSectionForLSDA(
 
//===--===//
 TargetLoweringObjectFileGOFF::TargetLoweringObjectFileGOFF() = default;
 
+void TargetLoweringObjectFileGOFF::getModuleMetadata(Module &M) {
+  // Construct the default names for the root SD and the ADA PR symbol.
+  StringRef FileName = sys::path::stem(M.getSourceFileName());
+  if (FileName.size() > 1 && FileName.starts_with('<') &&
+  FileName.ends_with('>'))
+FileName = FileName.substr(1, FileName.size() - 2);
+  DefaultRootSDName = Twine(FileName).concat("#C").str();

AidoP wrote:

The default root section should be a private section, a section with a name of 
1 space. The source file name affecting ABI is quite surprising and could 
easily lead to linker errors, especially when taking just the stem. For 
example, `clang src/a.c src/impl/a.c` would have issues.

Additionally I'm not sure if the file name can be relied on at all here. Is it 
guaranteed to be provided by a compiler frontend? Does it make sense for the 
file name to be interpreted as UTF-8 then converted to IBM-1047? It also needs 
to be normalised to deal with characters that are invalid for symbol names.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-09 Thread Kai Nacke via llvm-branch-commits


@@ -239,6 +298,63 @@ class GOFFWriter {
 GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
 : OS(OS), Asm(Asm) {}
 
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+  if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+  Section.getSDAttributes());
+writeSymbol(SD);
+  }
+
+  if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
+  ED.SectionLength = Asm.getSectionAddressSize(Section);
+writeSymbol(ED);
+  }
+
+  if (Section.isPR()) {
+GOFFSymbol PR(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getPRAttributes());
+PR.SectionLength = Asm.getSectionAddressSize(Section);
+if (Section.requiresNonZeroLength()) {

redstar wrote:

I talked to a colleague. Exactly this ^^^ case will not work. The binder gives 
no warning/error but it will cause problems at runtime because the environment 
parameter is zero.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-08 Thread Ulrich Weigand via llvm-branch-commits


@@ -16,34 +16,94 @@
 #define LLVM_MC_MCSECTIONGOFF_H
 
 #include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/MC/MCGOFFAttributes.h"
 #include "llvm/MC/MCSection.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/raw_ostream.h"
 
 namespace llvm {
 
 class MCExpr;
 
 class MCSectionGOFF final : public MCSection {
-private:
-  MCSection *Parent;
-  uint32_t Subsection;
+  // Parent of this section. Implies that the parent is emitted first.
+  MCSectionGOFF *Parent;
+
+  // The attributes of the GOFF symbols.
+  GOFF::SDAttr SDAttributes;
+  GOFF::EDAttr EDAttributes;
+  GOFF::PRAttr PRAttributes;
+
+  // The type of this section.
+  GOFF::ESDSymbolType SymbolType;
+
+  // Indicates that the PR symbol needs to set the length of the section to a
+  // non-zero value. This is only a problem with the ADA PR - the binder will
+  // generate an error in this case.
+  unsigned RequiresNonZeroLength : 1;
 
   friend class MCContext;
-  MCSectionGOFF(StringRef Name, SectionKind K, MCSection *P, uint32_t Sub)
+  MCSectionGOFF(StringRef Name, SectionKind K, GOFF::ESDSymbolType SymbolType,
+GOFF::SDAttr SDAttributes, GOFF::EDAttr EDAttributes,
+GOFF::PRAttr PRAttributes, MCSectionGOFF *Parent = nullptr)
   : MCSection(SV_GOFF, Name, K.isText(), /*IsVirtual=*/false, nullptr),
-Parent(P), Subsection(Sub) {}
+Parent(Parent), SDAttributes(SDAttributes), EDAttributes(EDAttributes),
+PRAttributes(PRAttributes), SymbolType(SymbolType) {}
 
 public:
   void printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
 raw_ostream &OS,
-uint32_t /*Subsection*/) const override {
-OS << "\t.section\t\"" << getName() << "\"\n";
+uint32_t Subsection) const override {
+switch (SymbolType) {
+case GOFF::ESD_ST_SectionDefinition:
+  OS << Name << " CSECT\n";
+  break;
+case GOFF::ESD_ST_ElementDefinition:
+  getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+  OS << Name << " CATTR\n";
+  break;
+case GOFF::ESD_ST_PartReference:
+  getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+  OS << Name << " XATTR\n";

uweigand wrote:

This looks wrong.  For a PR, you should print a CATTR (with the ED class name) 
using a PART attribute holding the PR name.   XATTR should be used when 
printing a symbol, e.g. to hold the PSECT attibute for the ADA section.  (Also, 
for full generality, you should probably emit the remaining section and symbol 
attributes with the CATTR and XATTR where applicable.)

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-08 Thread Kai Nacke via llvm-branch-commits


@@ -2759,6 +2760,12 @@ MCSection 
*TargetLoweringObjectFileXCOFF::getSectionForLSDA(
 
//===--===//
 TargetLoweringObjectFileGOFF::TargetLoweringObjectFileGOFF() = default;
 
+void TargetLoweringObjectFileGOFF::getModuleMetadata(Module &M) {
+  // Set the main file name if not set previously by the tool.
+  if (getContext().getMainFileName().empty())
+getContext().setMainFileName(M.getSourceFileName());

redstar wrote:

Not using anymore.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-08 Thread Kai Nacke via llvm-branch-commits


@@ -230,10 +230,11 @@ class MCObjectFileInfo {
   MCSection *GLJMPSection = nullptr;
 
   // GOFF specific sections.
-  MCSection *PPA1Section = nullptr;
-  MCSection *PPA2Section = nullptr;
-  MCSection *PPA2ListSection = nullptr;
-  MCSection *ADASection = nullptr;
+  MCSection *RootSDSection = nullptr;

redstar wrote:

Removed.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-08 Thread Kai Nacke via llvm-branch-commits


@@ -239,6 +298,63 @@ class GOFFWriter {
 GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
 : OS(OS), Asm(Asm) {}
 
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+  if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+  Section.getSDAttributes());
+writeSymbol(SD);
+  }
+
+  if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
+  ED.SectionLength = Asm.getSectionAddressSize(Section);
+writeSymbol(ED);
+  }
+
+  if (Section.isPR()) {
+GOFFSymbol PR(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getPRAttributes());
+PR.SectionLength = Asm.getSectionAddressSize(Section);
+if (Section.requiresNonZeroLength()) {

redstar wrote:

For this specific case I do not know what happens under the hood.
For an externally callable function, a function descriptor is generated in the 
ADA by the _binder_. From the LLVM point of view, the ADA would still be empty. 
The simple example is:
```
void empty() {}
```
Here, the ADA is empty. Still, the binder generates the function descriptor. A 
caller of this function can use a function descriptor in its own compilation 
unit:
```
DC  R(empty)
DC  V(empty)
```
I would expect that I get a binder error on `R(empty)` if no associated data 
area was given for the code section. But I have not tried.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-08 Thread Kai Nacke via llvm-branch-commits


@@ -26,6 +27,29 @@ GOFFObjectWriter &MCGOFFStreamer::getWriter() {
   return static_cast(getAssembler().getWriter());
 }
 
+void MCGOFFStreamer::initSections(bool /*NoExecStack*/,
+  const MCSubtargetInfo &STI) {
+  MCContext &Ctx = getContext();
+  // Emit the text section.
+  switchSection(Ctx.getObjectFileInfo()->getTextSection());
+}

redstar wrote:

Removed, not needed.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-08 Thread Kai Nacke via llvm-branch-commits

redstar wrote:

> > I use the ordinal number +1 of the section as the section number, but still 
> > need a counter for the symbols.
> 
> Can't we just set the ordinal to the correct value to begin with? ELF sets 
> the ordinals while writing out the sections; I think we might as well do the 
> same. (The point being that if we have already ensured we write sections in 
> the correct order, then we will only ever need to refer to ordinals of 
> sections that have already been written.) Then we'd be back to a single 
> counter used by the writer for all GOFF symbol records, those that come from 
> sections as well as those that come from symbols.

At first I was a bit confused about this, because the `MCAssembler` sets the 
ordinal. Well, it seems that the ELF writer overwrites those values. :-) Sure, 
I can do the same.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-08 Thread Kai Nacke via llvm-branch-commits


@@ -16,34 +16,95 @@
 #define LLVM_MC_MCSECTIONGOFF_H
 
 #include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/MC/MCGOFFAttributes.h"
 #include "llvm/MC/MCSection.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/raw_ostream.h"
 
 namespace llvm {
 
 class MCExpr;
 
 class MCSectionGOFF final : public MCSection {
-private:
-  MCSection *Parent;
-  uint32_t Subsection;
+  // Parent of this section. Implies that the parent is emitted first.
+  MCSectionGOFF *Parent;
+
+  // The attributes of the GOFF symbols.
+  GOFF::SDAttr SDAttributes;
+  GOFF::EDAttr EDAttributes;
+  GOFF::PRAttr PRAttributes;

redstar wrote:

Changed.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-08 Thread Kai Nacke via llvm-branch-commits


@@ -230,10 +230,11 @@ class MCObjectFileInfo {
   MCSection *GLJMPSection = nullptr;
 
   // GOFF specific sections.
-  MCSection *PPA1Section = nullptr;
-  MCSection *PPA2Section = nullptr;
-  MCSection *PPA2ListSection = nullptr;
-  MCSection *ADASection = nullptr;
+  MCSection *RootSDSection = nullptr;
+  MCSection *PPA2ListEDSection = nullptr;
+  MCSection *PPA2ListPRSection = nullptr;
+  MCSection *ADAEDSection = nullptr;
+  MCSection *ADAPRSection = nullptr;

redstar wrote:

Removed.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-07 Thread Kai Nacke via llvm-branch-commits


@@ -239,6 +298,63 @@ class GOFFWriter {
 GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
 : OS(OS), Asm(Asm) {}
 
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+  if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+  Section.getSDAttributes());
+writeSymbol(SD);
+  }
+
+  if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
+  ED.SectionLength = Asm.getSectionAddressSize(Section);
+writeSymbol(ED);
+  }
+
+  if (Section.isPR()) {
+GOFFSymbol PR(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getPRAttributes());
+PR.SectionLength = Asm.getSectionAddressSize(Section);
+if (Section.requiresNonZeroLength()) {

redstar wrote:

PR sections of size zero are allowed. However, if a text section is associated 
with an data section (the ADAEsdId field of the LD symbol of the text section 
is set to the PR symbol of the ADA) then the binder produces an error. This is 
a work-around for that situation.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-07 Thread Ulrich Weigand via llvm-branch-commits


@@ -16,34 +16,95 @@
 #define LLVM_MC_MCSECTIONGOFF_H
 
 #include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/MC/MCGOFFAttributes.h"
 #include "llvm/MC/MCSection.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/raw_ostream.h"
 
 namespace llvm {
 
 class MCExpr;
 
 class MCSectionGOFF final : public MCSection {
-private:
-  MCSection *Parent;
-  uint32_t Subsection;
+  // Parent of this section. Implies that the parent is emitted first.
+  MCSectionGOFF *Parent;
+
+  // The attributes of the GOFF symbols.
+  GOFF::SDAttr SDAttributes;
+  GOFF::EDAttr EDAttributes;
+  GOFF::PRAttr PRAttributes;

uweigand wrote:

union might be better?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-07 Thread Kai Nacke via llvm-branch-commits


@@ -16,34 +16,94 @@
 #define LLVM_MC_MCSECTIONGOFF_H
 
 #include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/MC/MCGOFFAttributes.h"
 #include "llvm/MC/MCSection.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/raw_ostream.h"
 
 namespace llvm {
 
 class MCExpr;
 
 class MCSectionGOFF final : public MCSection {
-private:
-  MCSection *Parent;
-  uint32_t Subsection;
+  // Parent of this section. Implies that the parent is emitted first.
+  MCSectionGOFF *Parent;
+
+  // The attributes of the GOFF symbols.
+  GOFF::SDAttr SDAttributes;
+  GOFF::EDAttr EDAttributes;
+  GOFF::PRAttr PRAttributes;
+
+  // The type of this section.
+  GOFF::ESDSymbolType SymbolType;
+
+  // Indicates that the PR symbol needs to set the length of the section to a
+  // non-zero value. This is only a problem with the ADA PR - the binder will
+  // generate an error in this case.
+  unsigned RequiresNonZeroLength : 1;
 
   friend class MCContext;
-  MCSectionGOFF(StringRef Name, SectionKind K, MCSection *P, uint32_t Sub)
+  MCSectionGOFF(StringRef Name, SectionKind K, GOFF::ESDSymbolType SymbolType,
+GOFF::SDAttr SDAttributes, GOFF::EDAttr EDAttributes,
+GOFF::PRAttr PRAttributes, MCSectionGOFF *Parent = nullptr)
   : MCSection(SV_GOFF, Name, K.isText(), /*IsVirtual=*/false, nullptr),
-Parent(P), Subsection(Sub) {}
+Parent(Parent), SDAttributes(SDAttributes), EDAttributes(EDAttributes),
+PRAttributes(PRAttributes), SymbolType(SymbolType) {}
 
 public:
   void printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
 raw_ostream &OS,
-uint32_t /*Subsection*/) const override {
-OS << "\t.section\t\"" << getName() << "\"\n";
+uint32_t Subsection) const override {
+switch (SymbolType) {
+case GOFF::ESD_ST_SectionDefinition:
+  OS << Name << " CSECT\n";
+  break;
+case GOFF::ESD_ST_ElementDefinition:
+  getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+  OS << Name << " CATTR\n";
+  break;
+case GOFF::ESD_ST_PartReference:
+  getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+  OS << Name << " XATTR\n";

redstar wrote:

Yes, true, I need to update my HLASM skills.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-07 Thread Kai Nacke via llvm-branch-commits


@@ -239,6 +298,63 @@ class GOFFWriter {
 GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
 : OS(OS), Asm(Asm) {}
 
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+  if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+  Section.getSDAttributes());
+writeSymbol(SD);
+  }
+
+  if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
+  ED.SectionLength = Asm.getSectionAddressSize(Section);
+writeSymbol(ED);
+  }
+
+  if (Section.isPR()) {
+GOFFSymbol PR(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getPRAttributes());
+PR.SectionLength = Asm.getSectionAddressSize(Section);
+if (Section.requiresNonZeroLength()) {

redstar wrote:

> Or, in the alternative, should we simply not set the ADA link if the target 
> section is empty? If an ADA section, it cannot actually be used for anything, 
> so do we even need to register it as ADA for a text section?

That is a simple solution, too. I am not sure if this works with the HLASM 
output. 

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-07 Thread Ulrich Weigand via llvm-branch-commits

uweigand wrote:

> I use the ordinal number +1 of the section as the section number, but still 
> need a counter for the symbols.

Can't we just set the ordinal to the correct value to begin with?  ELF sets the 
ordinals while writing out the sections; I think we might as well do the same.  
(The point being that if we have already ensured we write sections in the 
correct order, then we will only ever need to refer to ordinals of sections 
that have already been written.)  Then we'd be back to a single counter used by 
the writer for all GOFF symbol records, those that come from sections as well 
as those that come from symbols.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-07 Thread Ulrich Weigand via llvm-branch-commits


@@ -239,6 +298,63 @@ class GOFFWriter {
 GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
 : OS(OS), Asm(Asm) {}
 
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+  if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+  Section.getSDAttributes());
+writeSymbol(SD);
+  }
+
+  if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
+  ED.SectionLength = Asm.getSectionAddressSize(Section);
+writeSymbol(ED);
+  }
+
+  if (Section.isPR()) {
+GOFFSymbol PR(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getPRAttributes());
+PR.SectionLength = Asm.getSectionAddressSize(Section);
+if (Section.requiresNonZeroLength()) {

uweigand wrote:

I see.  I think we should implement this rule then - if a section is the target 
of an ADA link, it cannot be empty.  That would be preferable to upper layers 
having to remember setting this flag.  (I guess we could still have a flag 
internally, but that would get automatically set e.g. by `setADA`.)

Or, in the alternative, should we simply *not* set the ADA link if the target 
section is empty?  If an ADA section, it cannot actually be used for anything, 
so do we even need to register it as ADA for a text section?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-07 Thread Ulrich Weigand via llvm-branch-commits


@@ -671,24 +672,48 @@ MCContext::getELFUniqueIDForEntsize(StringRef 
SectionName, unsigned Flags,
   : std::nullopt;
 }
 
-MCSectionGOFF *MCContext::getGOFFSection(StringRef Section, SectionKind Kind,
- MCSection *Parent,
- uint32_t Subsection) {
+MCSectionGOFF *
+MCContext::getGOFFSection(SectionKind Kind, GOFF::ESDSymbolType SymbolType,
+  StringRef Name, GOFF::SDAttr SDAttributes,
+  GOFF::EDAttr EDAttributes, GOFF::PRAttr PRAttributes,
+  MCSection *Parent) {
+  GOFFSectionKey T{Name, SymbolType};
   // Do the lookup. If we don't have a hit, return a new section.
-  auto IterBool =
-  GOFFUniquingMap.insert(std::make_pair(Section.str(), nullptr));
+  auto IterBool = GOFFUniquingMap.insert(std::make_pair(T, nullptr));

uweigand wrote:

The way the key is defined means that we there can only be a single instance of 
a section with the same name and type.  For example, there can only be a single 
ED with name C_WSA64.   This doesn't look correct to me.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-07 Thread Kai Nacke via llvm-branch-commits


@@ -26,6 +27,29 @@ GOFFObjectWriter &MCGOFFStreamer::getWriter() {
   return static_cast(getAssembler().getWriter());
 }
 
+void MCGOFFStreamer::initSections(bool /*NoExecStack*/,
+  const MCSubtargetInfo &STI) {
+  MCContext &Ctx = getContext();
+  // Emit the text section.
+  switchSection(Ctx.getObjectFileInfo()->getTextSection());
+}
+
+namespace {
+// Make sure that all section are registered in the correct order.
+void registerSectionHierarchy(MCAssembler &Asm, MCSectionGOFF *Section) {
+  if (Section->isRegistered())
+return;
+  if (Section->getParent())
+registerSectionHierarchy(Asm, Section->getParent());
+  registerSectionHierarchy(Asm, Section);

redstar wrote:

Yes, that's a bug. It should call `Asm.registerSection()` instead.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-07 Thread Kai Nacke via llvm-branch-commits


@@ -239,6 +298,63 @@ class GOFFWriter {
 GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
 : OS(OS), Asm(Asm) {}
 
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+  if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+  Section.getSDAttributes());
+writeSymbol(SD);
+  }
+
+  if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())

redstar wrote:

> so it's size should be zero naturally?

Yes, that's true, and it makes the code easier.

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-07 Thread Ulrich Weigand via llvm-branch-commits


@@ -26,6 +27,29 @@ GOFFObjectWriter &MCGOFFStreamer::getWriter() {
   return static_cast(getAssembler().getWriter());
 }
 
+void MCGOFFStreamer::initSections(bool /*NoExecStack*/,
+  const MCSubtargetInfo &STI) {
+  MCContext &Ctx = getContext();
+  // Emit the text section.
+  switchSection(Ctx.getObjectFileInfo()->getTextSection());
+}

uweigand wrote:

How is this different from the default implementation of `initSections`?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-07 Thread Ulrich Weigand via llvm-branch-commits


@@ -26,6 +27,29 @@ GOFFObjectWriter &MCGOFFStreamer::getWriter() {
   return static_cast(getAssembler().getWriter());
 }
 
+void MCGOFFStreamer::initSections(bool /*NoExecStack*/,
+  const MCSubtargetInfo &STI) {
+  MCContext &Ctx = getContext();
+  // Emit the text section.
+  switchSection(Ctx.getObjectFileInfo()->getTextSection());
+}
+
+namespace {
+// Make sure that all section are registered in the correct order.
+void registerSectionHierarchy(MCAssembler &Asm, MCSectionGOFF *Section) {
+  if (Section->isRegistered())
+return;
+  if (Section->getParent())
+registerSectionHierarchy(Asm, Section->getParent());
+  registerSectionHierarchy(Asm, Section);

uweigand wrote:

Huh?  How is this not just an endless recursion?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)

2025-04-07 Thread Ulrich Weigand via llvm-branch-commits


@@ -239,6 +298,63 @@ class GOFFWriter {
 GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
 : OS(OS), Asm(Asm) {}
 
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+  if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+  Section.getSDAttributes());
+writeSymbol(SD);
+  }
+
+  if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+  Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())

uweigand wrote:

Do we really need a special flag for this?   As I understand it, the length 
should remain zero for EDs that have PRs inside, i.e. those that use 
GOFF::ESD_BA_Merge - can't we just check for that?   Also, in those cases no 
text should ever get emitted into the ED section, so it's size should be zero 
naturally?

https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


  1   2   >