<div dir="ltr">The other way to address this issue in theory would be to define how to align each .note section in a PT_NOTE segment. It is actually pretty easy to identify padding between .note sections if padding is just zero-initialized bytes, as each .note section always starts with a 4-byte "length" field which is always a non-zero value. Thus, if we just align each .note section to its alignment requirement and leave padding as-is, the result would be in theory readable.<div><br></div><div>Of course, the problem is that being readable in theory is different from being readable by the existing programs. So I don't think it is a practical solution (so I don't think we can do that in practice), but if we want to fix it at the ABI level, that's one way of doing it.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 11:51 AM Jake Ehrlich <<a href="mailto:jakehehrlich@google.com" target="_blank">jakehehrlich@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Rui is correct and I think pcc's proposal is the only way IMO. Consider two note sections with page alignment (or any large alignment) that are both 8 bytes (or anything significantly smaller than a page). It is fundamentally impossible to put those note sections in the same PT_NOTE segment. You can minimize the number of PT_LOAD segments by first sorting as in this change then emitting a PT_NOTE segment when the next one won't be at the expected 4-byte aligned location.<br><br>Ignoring the alignment require is possible but it means that sometimes unaligned reads will occur right?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 9:20 AM Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Mar 11, 2019 at 3:09 AM Peter Smith via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">peter.smith added a comment.<br>
<br>
I personally favour a separate PT_NOTE section per alignment, that gives a note parser simple rule to iterate through the section (the p_align field). I think ordering by decreasing alignment will work in practice for the note sections that we have now, but it may not be in the future. I also think that this is worth doing even if clang is changed to generate .note.gnu.property sections that are 4-byte aligned; clang will often use libraries compiled by gcc (or some other compiler) that does use 8-byte aligned sections.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I'm not sure if a separate PT_NOTE section per alignment would work for all cases. I don't think the size of a note section with 8-byte alignment is guaranteed to be a multiple of 8 byte. If that's permitted, there is a gap after a note section whose size is not a multiple of 8. So I guess the "most" correct approach would be to create a note segment for each note section. But perhaps I'm overthinking now...</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
There is a long glibc thread that covers a similar discussion in the gnu community <a href="https://sourceware.org/ml/libc-alpha/2018-08/msg00340.html" rel="noreferrer" target="_blank">https://sourceware.org/ml/libc-alpha/2018-08/msg00340.html</a> , it is quite long so I've pulled out a few bits of it here:<br>
<br>
- <a href="https://sourceware.org/ml/libc-alpha/2018-08/msg00344.html" rel="noreferrer" target="_blank">https://sourceware.org/ml/libc-alpha/2018-08/msg00344.html</a> and follow-up <a href="https://sourceware.org/ml/libc-alpha/2018-08/msg00347.html" rel="noreferrer" target="_blank">https://sourceware.org/ml/libc-alpha/2018-08/msg00347.html</a> on why two separate PT_NOTE sections were needed.<br>
- <a href="https://sourceware.org/ml/libc-alpha/2018-08/msg00468.html" rel="noreferrer" target="_blank">https://sourceware.org/ml/libc-alpha/2018-08/msg00468.html</a> rejection of changing ld bfd to that of gold and just setting the alignment of .gnu.property to 4-bytes. Ostensibly due to presence of large number of binaries with 8-byte aligned sections.<br>
<br>
>From what I can tell:<br>
<br>
- ld.bfd outputs a separate PT_NOTE per p_align.<br>
- ld.gold ignores the 8-byte alignment of the .note.gnu.property in the input object and changes it to 4 so that only one PT_NOTE is required.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>If ignoring the alignment requirement would work in practice, it is a tempting choice.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- glibc works for both, given that .note.gnu.property doesn't strictly need 8 byte alignment.<br>
<br>
<br>
Repository:<br>
rLLD LLVM Linker<br>
<br>
CHANGES SINCE LAST ACTION<br>
<a href="https://reviews.llvm.org/D59120/new/" rel="noreferrer" target="_blank">https://reviews.llvm.org/D59120/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D59120" rel="noreferrer" target="_blank">https://reviews.llvm.org/D59120</a><br>
<br>
<br>
<br>
</blockquote></div></div></blockquote></div>
</blockquote></div>