<div dir="ltr">Yes, it is always a pain when we have to keep information over the round-trip conversion from/to Native. Native format is really able to handle only fields we define to base Atom or Reference and not a subclass of them. This is, well, hard. This is like a roadblock that is always there when we do something with Reference. I think this needs fixing.<div><br></div><div>I once proposed or at least suggested that we remove Native file format from LLD. I still think that's not a bad idea at all -- no one is using Native and thus delivers no value currently, but it imposes burden to developers. This is not a good situation.</div><div><br></div><div>If we still want to maintain Native, conversion from/to Native needs to be easier to support. I can think of a few reasons why supporting Native is hard.</div><div><br></div><div>1. It is not extendable. It only recognizes base classes and not subclasses of Atom or References.</div><div><br></div><div>2. The file format is designed to be mmap()'able, so that you can just mmap the entire file and cast a struct to read it. It'd be very fast indeed -- but it can't support any optional field or something.</div><div><br></div><div>If I would design from scratch, I'd probably use a serializable data structure like Protocol Buffers or Thrust to represent Atoms and References, so that all that conversion is automatically done. They are fast enough and easy to use.</div><div><br></div><div>That being said, I think the short term solution for your need is to just add a new field to Reference.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 5, 2015 at 12:22 PM, Simon Atanasyan <span dir="ltr"><<a href="mailto:simon@atanasyan.com" target="_blank">simon@atanasyan.com</a>></span> 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::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>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Simon Atanasyan<br>
</font></span></blockquote></div><br></div>