<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 19, 2016 at 7:16 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> I think you want to remove "That means ..." part because it doesn't describe the behavior of this function.<br>
<br>
Done.<br>
<br>
> Why don't you store relocation indices to section pieces? It would be better than having parallel arrays.<br>
<br>
The common use is for SHF_MERGE sections that don't have relocations.<br>
The existing code is trying to pack it to be cache friendly (uses<br>
bitfield).<br>
<br>
I could just remove SplitInputSection and have MergeInputSection and<br>
EhInputSection declare their own Pieces array. The one in<br>
EhInputSection would have the first relocation of each piece. What do<br>
you think?<br></blockquote><div><br></div><div>Because of my previous change to use a hash table rather than doing binary search, I think cache friendliness of SectionPiece is now less important. So you may just want to add a new field. You may want to benchmark?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Please write a function comment why you needed this function (e.g. why .eh_frame needs special treament).<br>
<br>
Done.<br>
<br>
New patch attached.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>