<html>
<head>
</head>
<body bgcolor="#FFFFFF" text="#000000">
Shankar, thank you again.<br>
Now I see how this trick is done in MIPS, so I'll use it as a
reference.<br>
<br>
- Denis.<br>
<br>
<div class="moz-cite-prefix">On 01/12/2015 07:08 PM, Shankar
Easwaran wrote:<br>
</div>
<blockquote cite="mid:54B3F196.1030505@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 use the codemodel to say that the code
is Thumb for thumb code.<br>
<br>
On 1/12/2015 8:22 AM, Denis Protivensky wrote:<br>
> 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>
> On 01/02/2015 09:32 PM, Shankar Easwaran wrote:<br>
><br>
> 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="mailto:LLVMdev@cs.uiuc.edu">mailto: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>
> Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by the Linux Foundation<br>
><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>