[llvm] [RISCV] Improvements to .note.gnu.property section. (PR #151436)

[Ming-Yi Lai via llvm-commits]

================
@@ -83,29 +86,21 @@ void RISCVTargetStreamer::emitNoteGnuPropertySection(
   OutStreamer.switchSection(NoteSection);
 
   // Emit the note header
-  OutStreamer.emitIntValue(4, 4); // n_namsz
-
-  MCSymbol *const NDescBeginSym = Ctx.createTempSymbol();
-  MCSymbol *const NDescEndSym = Ctx.createTempSymbol();
-  const MCExpr *const NDescSzExpr =
-      MCBinaryExpr::createSub(MCSymbolRefExpr::create(NDescEndSym, Ctx),
-                              MCSymbolRefExpr::create(NDescBeginSym, Ctx), Ctx);
-
-  OutStreamer.emitValue(NDescSzExpr, 4);                    // n_descsz
+  OutStreamer.emitValueToAlignment(NoteAlign);
----------------
mylai-mtk wrote:

This doesn't do any good here, since the section itself already had an alignment, so aligning again won't have any effect.

However, the section's alignment is actually off-the-spec (I can't find any spec saying that a SHT_NOTE or .note.gnu.property section should have its address aligned), but it's there because I referenced the implementation of `yaml2obj`, and the assertion of section alignment is in it: https://github.com/llvm/llvm-project/blob/f62370290a66f8d3a47a4b25c3896983424f97bd/llvm/lib/ObjectYAML/ELFEmitter.cpp#L1825

As of why I resort to referencing `yaml2obj`, it's because some tests need to be built using it, so I conform to its standard when the spec isn't clear.

BTW, I have to remind that the gABI clearly states alignments are required for the `desc` fields:
> # namesz and name
> The first namesz bytes in name contain a null-terminated character representation of the entry's owner or originator. There is no formal mechanism for avoiding name conflicts. By convention, vendors use their own name, such as XYZ Computer Company, as the identifier. If no name is present, namesz contains 0. **Padding is present, if necessary, to ensure 8 or 4-byte alignment for the descriptor (depending on whether the file is a 64-bit or 32-bit object).** Such padding is not included in namesz.
> # descsz and desc
> The first descsz bytes in desc hold the note descriptor. The ABI places no constraints on a descriptor's contents. If no descriptor is present, descsz contains 0. **Padding is present, if necessary, to ensure 8 or 4-byte alignment for the next note entry (depending on whether the file is a 64-bit or 32-bit object).** Such padding is not included in descsz.
>
> -- https://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section

, which is why alignment directives were there at the beginning. The change to omit alignment directives here and there are legal only if we do our address calculations correctly and more importantly, based on the assumption that the section beginning is aligned. Here I need to emphasize: this assumption is unfortunately off-the-spec from my perspective.

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