Linker Option support for ELF

John_Reagan · January 4, 2018, 5:14pm

We use .note descriptors with ELF on OpenVMS. We have self-describing entries with tags and lengths. The compiler encodes stuff for the linker such as compiler version, compilation date-time, module name, final severity of the compilation, etc. The linker itself then adds/modifies the .note entries to insert linker version, link date/time, etc. We also use .notes to record floating point settings used on the compilation (ie, VAX float vs IEEE float with denorms vs IEEE float without denorms, etc.) We currently don't have options that impact the linker's behavior but that is reasonable.

I would like to see something with tags so that our linker can identify .notes that it cares about vs .notes that it should ignore.

For our x86 work, we're starting to generate them at the MC boundary so they show up both in the ELF and in an .s file.

What we plan to do is to generate module metadata which would then get turned into MC calls.

Here's what we generate on OpenVMS Itanium (we don't do .s files there)

Analyze Object File 4-JAN-2018 11:44:44.78 Page 1
WORK20:[JREAGAN]HW.OBJ;73
ANALYZ I01-55

This is an OpenVMS IA64 (Elf format) object file

Module Identification Information, in note section 2.

 Module name:                                &quot;HW&quot;
 Module version:                             &quot;V1\.0&quot;
 Creation date/time:                         &quot; 9\-JUN\-2017 10:30&quot;
 Language name:                              &quot;VSI C V7\.4\-001&quot;

Elf Header Information, at file address 0.

 Class:                                      ELF\-64
 Data:                                       Little\-endian byte order
 Elf Header Version:                         1\.
 OS ABI:                                     OpenVMS
 OS ABI Version:                             2\.
 Type:                                       Object
 Machine Architecture:                       IA\_64
 Elf File Version:                           1\.
 VMS Completion Code:                        SUCCESS

...

SECTION DATA 2. (0002) SHDR$K_SHT_NOTE 00000000000000A8 (168.) bytes
".note"
FileAddr Offset in Section 2. (0002)
-------- ---------------------------
000000C0 00000000 Note Entry 0.
000000C0 00000000 Note Name Size: 0000000000000008 8. nhdr$q_nh_namesz
000000C8 00000008 Note Descriptor size: 000000000000002A 42. nhdr$q_nh_descsz
000000D0 00000010 Note Type: 0000000000000001 1. NT_VMS_MHD nhdr$q_nh_type
000000D8 00000018 Note Name: "IPF/VMS"
000000E0 00000020 Descriptor:
000000E0 00000020 Creation Date/Time: " 9-JUN-2017 10:30"
000000F1 00000031 Last Patch Date/Time: " 9-JUN-2017 10:30"
00000102 00000042 Module Name: "HW"
00000105 00000045 Module Version: "V1.0"

00000110 00000050 Note Entry 1.
00000110 00000050 Note Name Size: 0000000000000008 8. nhdr$q_nh_namesz
00000118 00000058 Note Descriptor size: 000000000000000F 15. nhdr$q_nh_descsz
00000120 00000060 Note Type: 0000000000000002 2. NT_VMS_LNM nhdr$q_nh_type
00000128 00000068 Note Name: "IPF/VMS"
00000130 00000070 Descriptor:
00000130 00000070 Language Name: "VSI C V7.4-001"

00000140 00000080 Note Entry 2.
00000140 00000080 Note Name Size: 0000000000000008 8. nhdr$q_nh_namesz
00000148 00000088 Note Descriptor size: 0000000000000008 8. nhdr$q_nh_descsz
00000150 00000090 Note Type: 0000000000000006 6. NT_VMS_FPMODE nhdr$q_nh_type
00000158 00000098 Note Name: "IPF/VMS"
00000160 000000A0 Descriptor:
00000160 000000A0 Floating-Point Mode: 0000000009800000 IEEE DENORM_RESULTS

On OpenVMS x86, here's what we have in our .s files at the moment (subject to change)

.section .note,"",@note
.quad 8
.quad 44
.quad 1
.ascii "IPF/VMS"
.byte 0
.ascii " 4-JAN-2018 11:49"
.ascii ".MAIN."
.byte 0
.ascii "V1"
.byte 0
.align 8
.quad 8
.quad 14
.quad 2
.ascii "IPF/VMS"
.byte 0
.ascii "XMAC X6.0-004"
.byte 0
.align 8

Saleem_Abdulrasool1 · January 4, 2018, 6:59pm

We use .note descriptors with ELF on OpenVMS. We have self-describing
entries with tags and lengths. The compiler encodes stuff for the linker
such as compiler version, compilation date-time, module name, final
severity of the compilation, etc. The linker itself then adds/modifies the
.note entries to insert linker version, link date/time, etc. We also use
.notes to record floating point settings used on the compilation (ie, VAX
float vs IEEE float with denorms vs IEEE float without denorms, etc.) We
currently don't have options that impact the linker's behavior but that is
reasonable.

The note that I am describing would be part of the LLVM namespace. It
would be named ".note.linker-options". These notes should *not* be
preserved across the actual link. The notes that you are describing sound
very much like the ones in the ARM ELF specification (although they call
them attributes).

I would like to see something with tags so that our linker can identify
.notes that it cares about vs .notes that it should ignore.

Since they are in the vendor namespace, you should already be able to
determine that. You are using a different vendor namespace, and the two
would not collide and you would be able to easily identify the notes that
you can ignore. Unless your frontend emits the metadata, no such note
would even be created in the first place.

For our x86 work, we're starting to generate them at the MC boundary so
they show up both in the ELF and in an .s file.

Yes, this is the same as what happens here.