<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=koi8-r">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p><span style="color: rgb(33, 33, 33); font-size: 12pt;"><span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">Thanks for your ideas, Sean !</span><br>
</span></p>
<p><span style="color: rgb(33, 33, 33); font-size: 12pt;"><br>
</span></p>
<p><span style="color: rgb(33, 33, 33); font-size: 12pt;">><span style="color: rgb(33, 33, 33); font-family: "Segoe UI", "Segoe WP", "Segoe UI WPC", Tahoma, Arial, sans-serif; font-size: 15px; background-color: rgb(255, 255, 255);">The bug is not likely to
be corrupted data in the decompressed output (that is just calling into a gzip routine or something). You shouldn't have to dump/printf->trace from memory during boot to see that data since the "real" kernel binary that is being decompressed into that memory
region is probably already somewhere > in your build tree (arch/x86/boot/compressed/Makefile seems like it has the details; </span></span></p>
<div style="">
<div style="">
<div dir="ltr" style="">
<div class="gmail_extra" style="">
<div class="gmail_quote" style="">
<div style="color: rgb(33, 33, 33);"><br>
</div>
<div style="color: rgb(33, 33, 33);">Yeah, what I mean, it not just decompresses it, it also applies relocations to the decompressed output:<br>
</div>
<div style="color: rgb(33, 33, 33);">
<div>__decompress(input_data, input_len, NULL, NULL, output, output_len, <span style="font-size: 12pt;">NULL, error);</span></div>
<div>parse_elf(output);</div>
<div>handle_relocations(output, output_len, virt_addr);<br>
</div>
<div><br>
</div>
</div>
<div style="color: rgb(33, 33, 33);">M<span style="font-size: 12pt;">y idea of quick dumping was based on a some experience for one of FreeBSD loaders I fixed earlier. It was very short (512 bytes if I am not mistaken) and just quick look on LLD and bfd linked hex
views revealed the reason instantly. LLD linked binary was like corrupted with 4 bytes holes. All other code around was equal. That showed that we just did not apply one of relocations (R_386_16 I think) at all.</span></div>
<div style="color: rgb(33, 33, 33);"><br>
</div>
<div style="color: rgb(33, 33, 33);">So main idea of dumping was to check if there is something obviously wrong. May be it was not the best idea :) I want to try though.<br>
</div>
<div style="color: rgb(33, 33, 33);"><br>
</div>
<div style="color: rgb(33, 33, 33);">
<div style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">
> Grepping around, it seems like they build this list of relocations based on some sort of homegrown tooling in arch/x86/tools/. E.g. look at arch/x86/tools/relocs.c. <br>
</div>
<div style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">
<br>
</div>
<div style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">
<div><span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">So I am also suspecting it is something relative to relocations, my</span> suspicion also based on fact that
we had to </div>
<div>implement --emit-relocs option to support how they handle it.</div>
<div><span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);"><span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">This
is new feature for LLD and can probably still may have bugs (last part was committed on this friday)</span><span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);"> and
needs testing.</span><br>
</span></div>
<div><span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);"><br>
</span></div>
<div><span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">Details about how they use --emit-relocs was in next comment: <a href="https://reviews.llvm.org/D28612#647277">https://reviews.llvm.org/D28612#647277</a>. </span></div>
<div><span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">In short --emit-relocs generates .rel[a].xxx sections in output,</span></div>
<div><span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">they extract these sections using objdump and wrap it into separate binary with own format. </span></div>
<div><span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">And use this data for self-doing relocatations.</span></div>
<div><br>
</div>
<div><span style="color: rgb(33, 33, 33); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);"></span></div>
</div>
</div>
<div dir="ltr" style="font-size: 12pt; background-color: rgb(255, 255, 255);">
<div style="">
<div style="">
<div dir="ltr" style=""><span class="gmail-HOEnZb"><font>
<div class="gmail_extra" style=""><font color="#212121">George.</font><font color="#212121" face="calibri, arial, helvetica, sans-serif"></font><br>
</div>
</font></span></div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>