<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 24 October 2014 07:05, Shan Hai <span dir="ltr"><<a href="mailto:shan.hai@windriver.com" target="_blank">shan.hai@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":48k" class="a3s" style="overflow:hidden">Some header fields of ELF were read with wrong size on 64bit<br>
big-endian machine, fix it by reading the fields with read64<br>
instead of read32.</div></blockquote></div><br>For fixes like this which set of all sorts of alarm bells, please include more justification.</div><div class="gmail_extra"><br></div><div class="gmail_extra">From a quick look at the code my interpretation is that the values in the segment structure are 64-bit but they were being read using 32-bit accessors (read32). On a little-endian 64-bit machine (x86-64, aarch64) when the values fit into a 32-bit value the right half was read and it still worked. Then someone tried a 64-bit big-endian build host (I'm guessing is a ppc64 or mips64), and the values read are either 0 (if the size fits in a 32-bit type) or corrupted (if larger).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Am I right? Either way, the commit log needs to be clear - the message should *why* it does something, not *what* it does.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Finally, do we really need to patch a fork? We've got the full source alongside the recipe, let's just fix it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This also brings up the point that we really need to do something about ldconfig-native. CC'ing Khem, would anyone be able to liaise with upstream and either update our fork or see if upstream would care about our need for ldconfig-native?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ross</div></div>