<p dir="ltr">I'll gladly write a test for it, however I'll only be available to work on it again on Thursday or Friday. Is that ok? </p>
<div class="gmail_quote">On Jul 28, 2013 1:56 AM, "Rui Ueyama" <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Thanks Ron,<div><br></div><div>I haven't looked at the stackoverflow question to be on the safe side, but looks like we can say that the DUMPBIN output strongly suggest that the value stored at the relocation site should be added as an addend. At least it will cause no harm if the addend is zero. So I'm OK with this patch.</div>


<div><br></div><div>If our assumption is wrong, it'll be proved to be wrong pretty easily, as it'll become a obvious bug. I don't worry about that.</div><div><br></div><div>Could you write a test? Or if you are not sure how to test it, I can write a test for you.</div>


</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 27, 2013 at 10:49 AM, Ron Ofir <span dir="ltr"><<a href="mailto:ron.ofir@gmail.com" target="_blank">ron.ofir@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Here's what little I have found so far:</p>
<p dir="ltr">1. In the MS COFF spec, chapter 5.6.2 "Base Relocation Types", it is said that "The base relocation applies all 32 bits of the difference to the 32-bit field at offset", which I guess means that the relocation should take into account whatever address is already stored at the specified offset. However, chapter 5.6 (the .reloc section) is only relevant to image files, and not object files.<br>




2. The dumpbin utility adds a column named "Applied To" when printing the relocations table, which seems to always (no matter the relocation type) contain the value which is stored at the relocation site.<br>
3. The Relocation Directives chapter in the DJGPP COFF Specification clearly states that the value currently stored at the location should be added to the address of the symbol pointed to by the relocation table entry. However, it is DJGPP and not MS... </p>


<div><div>

<div class="gmail_quote">On Jul 27, 2013 3:52 PM, "Ron Ofir" <<a href="mailto:ron.ofir@gmail.com" target="_blank">ron.ofir@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<p dir="ltr">I have added some other sources of information I've found to my stackoverflow question, could you take a look there? </p>
<div class="gmail_quote">On Jul 27, 2013 3:27 PM, "Nico Rieck" <<a href="mailto:nico.rieck@gmail.com" target="_blank">nico.rieck@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




On <a href="tel:27.07.2013%2013" value="+12707201313" target="_blank">27.07.2013 13</a>:07, Chandler Carruth wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If this isn't covered by the spec, we shouldn't use stackoverflow to figure<br>
it out. Instead, Rui may need to confirm of refute it manually. =/<br>
</blockquote>
<br>
I've seen this for SECREL and ADDR32NB relocations. Also, dumpbin has an "Applied To" column.<br>
<br>
For example, these are relocations for .pdata, generated by MSVC, denoting start and end for a 0x30 byte main() and it's unwind info:<br>
<br>
RELOCATIONS #6<br>
                                                Symbol    Symbol<br>
 Offset    Type              Applied To         Index     Name<br>
 --------  ----------------  -----------------  --------  ------<br>
 00000000  ADDR32NB                   00000000        11  $LN10<br>
 00000004  ADDR32NB                   00000030        11  $LN10<br>
 00000008  ADDR32NB                   00000000        14  $unwind$main<br>
<br>
<br>
-Nico<br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</blockquote></div>
</blockquote></div>
</div></div><br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>
</blockquote></div>