[lld] [AArch64][GCS][LLD] Introduce -zgcs-report-dynamic Command Line Option (PR #127787)

[Peter Smith via llvm-commits]

================
@@ -1418,6 +1425,24 @@ std::vector<uint32_t> SharedFile::parseVerneed(const ELFFile<ELFT> &obj,
   return verneeds;
 }
 
+// To determine if a shared file can support the AArch64 GCS extension, the
+// program headers for the object need to be read. This ensures when input
+// options are read, appropriate warning/error messages can be emitted depending
+// on the user's command line options.
+template <typename ELFT>
+uint64_t
+SharedFile::parseGnuAttributes(const typename ELFT::PhdrRange headers) {
+  if (numElfPhdrs == 0)
+    return 0;
+  uint64_t attributes = 0;
+  for (unsigned i = 0; i < numElfPhdrs; i++)
----------------
smithp35 wrote:

I don't think that's how the PT_GNU_PROPERTY program header works.
The `p_flags` is generic ELF (see p_flags table in https://www.sco.com/developers/gabi/latest/ch5.pheader.html)

The p_offset and p_filesz give the location of the contents of the `.note.gnu.property section` which has the same structure as if it was in a relocatable object. You'll need to parse that contents of the file to look for GCS.

You should be able to reuse the code for parsing the notes section from a relocatable object.

If that code is too specific to an ELF section, then you could search the shared-libraries section header table. Strictly speaking this doesn't have to be there as it can be stripped, however LLD already seems to depend on it being present for other parts of parsing.

FWIW the Android Bionic Linker file https://android.googlesource.com/platform//bionic/+/16c23883bd707cb7b9827c44211a6cc5879e5032/linker/linker_note_gnu_property.cpp is what the Dynamic Linker does to process the PT_GNU_PROPERTY program header.

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