<html>
  <head>
    
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Thanks, Shankar.<br>
    <br>
    I needed to override all the places where st_value had been used,
    and it worked.<br>
    <br>
    But there another problem appeared: after correcting all atoms, I
    cannot distinguish between ARM and Thumb symbols in the further
    stages when fixing up relocations.<br>
    <br>
    I used to check targetVAddress (in terms of the relocation handler)
    since it contained 1 in the least bit when addressing Thumb symbols.
    Now targetVAddress always contains 0 in the least bit, because atoms
    are properly aligned and have proper contents.<br>
    <br>
    I tried applying a workaround and use dyn_cast to retrieve
    information from overridden ARMELFDefinedAtoms, but DefinedAtoms'
    children do not support dyn_casts.<br>
    <br>
    In general, I can describe the issue as inability to pass extra
    information between linking stages (passes).<br>
    Is there a way to do that?<br>
    <br>
    The solution I see is to add a sort of custom context with abstract
    interface passed along different stages, and directly cast it to
    specific implementation where needed. That's a lot of changes
    though, so I'd like to hear more thoughts.<br>
    <br>
    Regards,<br>
      Denis.<br>
    <br>
    <div class="moz-cite-prefix">On 01/02/2015 09:32 PM, Shankar
      Easwaran wrote:<br>
    </div>
    <blockquote cite="mid:54A6E453.3010006@codeaurora.org" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <meta name="Generator" content="MS Exchange Server version
        08.03.0377.000">
      <title>Re: [LLVMdev] [lld] ARM/Thumb atom forming</title>
      <!-- Converted from text/plain format -->
      <p><font size="2">You could just override symbolContentSize in the
          ARM Reader (remove the<br>
          last bit to indicate thumb).<br>
          <br>
          Shankar Easwaran<br>
          <br>
          On 12/24/2014 3:09 AM, Denis Protivensky wrote:<br>
          > Hi guys,<br>
          ><br>
          > I'm working on ARM architecture support for lld.<br>
          > I faced the problem with ARM/Thumb symbols described
          below.<br>
          ><br>
          > ARM ELF Reference specifies that symbols addressing Thumb
          instructions<br>
          > have zero bit of st_value field set (see 4.5.3).<br>
          > General ELF Reference says that st_value holds virtual
          address offset<br>
          > from the beginning of the section<br>
          > for executable files and shared objects (see Chapter 4 -
          Symbol Values).<br>
          ><br>
          > When atoms are created in ELFFile::createAtoms, their
          content size and<br>
          > content data, and their addresses are formed using
          st_value.<br>
          > Since st_value has zero bit set for symbols addressing
          Thumb<br>
          > instructions, corresponding atoms' addresses are always<br>
          > one byte ahead of real values.<br>
          > Content size and, therefore, content data may also be
          wrong for both ARM<br>
          > and Thumb symbols depending on their order (see
          ELFFile::symbolContentSize):<br>
          > when content size is calculated, it takes the difference
          between offsets<br>
          > of two adjacent symbols, and if one of them is Thumb, and
          the other is not,<br>
          > the resulting value will be one byte smaller or one byte
          larger than<br>
          > expected.<br>
          > Therefore, atom's content data is also malformed since it
          uses given<br>
          > miscalculated content size value.<br>
          ><br>
          > Such a wrong behavior results in:<br>
          > - situations when the very first instruction of an atom
          has the first<br>
          > byte set to zero<br>
          > (if there's a gap between previous atom and the current,
          the initial<br>
          > instruction's first byte is skipped)<br>
          > - situations when the very first instruction is split
          between two atoms<br>
          > (the right atom which should hold the instruction, and
          the<br>
          > previous one, which "stole" the very first byte of the
          initial instruction)<br>
          ><br>
          > Is there a way to override this behavior so that both ARM
          and Thumb atoms<br>
          > formed correctly, and that I can distinguish between them
          in the later<br>
          > stages<br>
          > for proper relocation calculations?<br>
          ><br>
          > Regards!<br>
          ><br>
          > _______________________________________________<br>
          > LLVM Developers mailing list<br>
          > <a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a moz-do-not-send="true"
            href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br>
          > <a moz-do-not-send="true"
            href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
          ><br>
          ><br>
          <br>
          <br>
          --<br>
          Qualcomm Innovation Center, Inc. is a member of Code Aurora
          Forum, hosted by the Linux Foundation<br>
          <br>
        </font>
      </p>
    </blockquote>
    <br>
  </body>
</html>