ABI document
Vivek Das Mohapatra
vivek@collabora.com
Wed Sep 2 17:29:49 GMT 2020
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Incorporate-feedback-and-add-DOCUMENTME-tags-where-m.patch
Type: text/x-diff
Size: 15931 bytes
Desc:
URL: <https://sourceware.org/pipermail/gnu-gabi/attachments/20200902/75c6e29a/attachment.bin>
More information about the Gnu-gabi
mailing list