This patch is cumulative with the last one.

> I can't tell whether the formatting is okay, and whether we need to add
> markup (like ``) for program text.

I asked and was told it was more important to get the actual
content agreed before we worried about that (and tbh the
content is the hard part).

> Can you dig out a link to a document that describes for the format of
> the GNU_EH_FRAME segment?

Done.

> I think this should also say that the virtual address range must be
> covered by an earlier PT_LOAD segment.

Done.

>> +PT_GNU_STACK     0x6474e551
>> +  Otherwise the stack is executable (the default).
>
> The default depends on the architecture, I think.

Fixed.

> I think we have differing behavior in regards to the size of the
> segment.  glibc ignores it, other implementations may use it to set the
> stack size.

Annotated.

>> +PT_GNU_RELRO     0x6474e552
>> +
>> +  The specified segment should be made read-only once run-time linking
>> +  has completed.
>
> I think it's relocation of this object, not the entire linking
> operation.

Fixed.

> Also we should try to sketch the interaction with PT_LOAD.

Not done yet.

>> +PT_GNU_PROPERTY  0x6474e553
>> +  some action before loading and ELF file (eg AArch64 BTI or intel CET)
>
> “Intel”

Fixed.

> The requirement could be worded better.  It must only be present if
> these features are to be enabled.

Clarified.

>> +  Properties are sorted in ascending order of pr_type;
>> +
>> +  pr_data is aligned to 4 bytes in 32-bit objects and 8 bytes in 64-bit ones.
>
> What's the overall alignment of the segment?  8 bytes on 64-bit?

Clarified. Is explicitly given by the p_align of the PT_* program header.

> This also has to say where the padding is inserted: before pr_data?
> After Elf_Prop?  I think it's the latter, and that Elf_Prop is aligned
> even if the pr_data member is absent.

Clairified. Always aligned. The padding is as laid out in the struct
given, so after pr_data.

>> +  GNU_PROPERTY_STACK_SIZE  0x1
>> +
>> +  A native format & size integer specifying the minimum stack size.
>> +  The linker should pick the highest instance of this from all relocatable
>> +  objects in the link chain and ensure the stack is at least this big.
>
> So this is an Elf*_Addr?

I guess, but explicitly defined in the doc now.

>> +  GNU_PROPERTY_NO_COPY_ON_PROTECTED 0x2
>> +  This type has a PR_DATASZ of 0.
>
> “pr_datasz field”?

Fixed.

>> +DT_GNU_PRELINKED  0x6ffffdf5
>> +
> That's not good for reproducibility (but then prelink results depend

Agreed, but that seems to be how prelinking works.

>> +DT_GNU_CONFLICTSZ 0x6ffffdf6
>> +DT_GNU_LIBLISTSZ  0x6ffffdf7
> It would be nice to add a link there to the prelink documentation.
> (There's a prelink.tex file in the sources.)

Couldn't see this - perhaps I was looking in the wrong place?


>> +DT_GNU_HASH       0x6ffffef5
> Do we have a format documentation for those?

No - added a note that this may need to be reversed from the
glibc source.

>> +DT_GNU_CONFLICT   0x6ffffef8
>> +DT_GNU_LIBLIST    0x6ffffef9
>
> Maybe group this with the earlier prelink items?

Moved.

>> +Section Headers
>> +===============
>
>> +SHT_GNU_verdef             0x6ffffffd
>> +SHT_GNU_verneed            0x6ffffffe
>> +SHT_GNU_versym             0x6fffffff
> I think the canonical reference for these is:
>
>  <https://www.akkadia.org/drepper/symbol-versioning>

Documented and references to LSB with the details given.

>> +Note section descriptors (SHT_NOTE extensions)
>> +==============================================
>
>> +NT_GNU_BUILD_ID        3
>> +
>> +  descsz bytes of build-id data.
>> +  Typically presented as a hex string.
>
> But stored in binary?

Yes.

> Maybe reference the ld documentation here, and say that the actual
> computation mechanism is unspecified?

Documented as binary+opaque, and the required unique-ness properties
noted.