[LLVMdev] [lld] ARM/Thumb atom forming

[Denis Protivensky]

Thanks, Shankar.

I needed to override all the places where st_value had been used, and it worked.

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.

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.

I tried applying a workaround and use dyn_cast to retrieve information from overridden ARMELFDefinedAtoms, but DefinedAtoms' children do not support dyn_casts.

In general, I can describe the issue as inability to pass extra information between linking stages (passes).
Is there a way to do that?

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.

Regards,
  Denis.

On 01/02/2015 09:32 PM, Shankar Easwaran wrote:

You could just override symbolContentSize in the ARM Reader (remove the
last bit to indicate thumb).

Shankar Easwaran

On 12/24/2014 3:09 AM, Denis Protivensky wrote:
> Hi guys,
>
> I'm working on ARM architecture support for lld.
> I faced the problem with ARM/Thumb symbols described below.
>
> ARM ELF Reference specifies that symbols addressing Thumb instructions
> have zero bit of st_value field set (see 4.5.3).
> General ELF Reference says that st_value holds virtual address offset
> from the beginning of the section
> for executable files and shared objects (see Chapter 4 - Symbol Values).
>
> When atoms are created in ELFFile::createAtoms, their content size and
> content data, and their addresses are formed using st_value.
> Since st_value has zero bit set for symbols addressing Thumb
> instructions, corresponding atoms' addresses are always
> one byte ahead of real values.
> Content size and, therefore, content data may also be wrong for both ARM
> and Thumb symbols depending on their order (see ELFFile::symbolContentSize):
> when content size is calculated, it takes the difference between offsets
> of two adjacent symbols, and if one of them is Thumb, and the other is not,
> the resulting value will be one byte smaller or one byte larger than
> expected.
> Therefore, atom's content data is also malformed since it uses given
> miscalculated content size value.
>
> Such a wrong behavior results in:
> - situations when the very first instruction of an atom has the first
> byte set to zero
> (if there's a gap between previous atom and the current, the initial
> instruction's first byte is skipped)
> - situations when the very first instruction is split between two atoms
> (the right atom which should hold the instruction, and the
> previous one, which "stole" the very first byte of the initial instruction)
>
> Is there a way to override this behavior so that both ARM and Thumb atoms
> formed correctly, and that I can distinguish between them in the later
> stages
> for proper relocation calculations?
>
> Regards!
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150112/47406058/attachment.html>