<div dir="ltr">Can we remove Native format support? I'd like to get input from anyone who wants to keep the current Native format in LLD.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 5, 2015 at 2:03 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The only way currently is to create a new reference, unless we can think of adding some target specific metadata information in the Atom model.<br>
<br>
This has come up over and over again, we need something in the Atom model to store information that is target specific.<br>
<br>
Shankar Easwaran<div><div class="h5"><br>
<br>
On 2/5/2015 2:22 PM, Simon Atanasyan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I need an advice on implementation of a very specific kind of relocations<br>
used by MIPS N64 ABI. As usual the main problem is how to pass target specific<br>
data over Native/YAML conversion barrier.<br>
<br>
In this ABI relocation record r_info field in fact consists of five subfields:<br>
* r_sym   - symbol index<br>
* r_ssym  - special symbol<br>
* r_type3 - third relocation type<br>
* r_type2 - second relocation type<br>
* r_type  - first relocation type<br>
<br>
Up to three these relocations applied one by one. The first relocation uses<br>
an addendum from the relocation record. Each subsequent relocation takes as<br>
its addend the result of the previous operation. Only the final operation<br>
actually modifies the location relocated. The first relocation uses as<br>
a reference symbol specified by the r_sym field. The third relocation<br>
assumes NULL symbol.<br>
<br>
The most interesting case is the second relocation. It uses the special<br>
symbol value given by the r_ssym field. This field can contain four<br>
predefined values:<br>
* RSS_UNDEF - zero value<br>
* RSS_GP    - value of gp symbol<br>
* RSS_GP0   - gp0 value taken from the .MIPS.options or .reginfo section<br>
* RSS_LOC   - address of location being relocated<br>
<br>
So the problem is how to store these four constants in the<br>
lld::Reference object.<br>
The RSS_UNDEF is obviously not a problem. To represent the RSS_GP value I can<br>
set an AbsoluteAtom created for the "_gp" as the reference's target. But what<br>
about RSS_GP0 and RSS_LOC? I am considering the following approaches but cannot<br>
select the best one:<br>
<br>
a) Create AbsoluteAtom for each of these cases and set them as the<br>
reference's target.<br>
    The problem is that these atoms are fake and should not go to the<br>
symbol table.<br>
    One more problem is to select unique names for these atoms.<br>
b) Use two high bits of lld::Reference::_kindValue field to encode<br>
RSS_xxx value.<br>
    Then decode these bits in the RelocationHandler to calculate result<br>
of relocation.<br>
    In that case the problem is how to represent a relocation kind<br>
value in YAML format.<br>
    The simple xxxRelocationStringTable::<u></u>kindStrings[] array will not satisfy us.<br>
c) Add one more field to the lld::Reference class. Something like the<br>
DefinedAtom::CodeModel<br>
    field.<br>
<br>
Any advices, ideas, and/or objections are much appreciated.<br>
<br>
</blockquote>
<br>
<br>
-- <br></div></div>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
<br>
</blockquote></div><br></div>