<div dir="ltr">There are two questions.<div><br></div><div>Firstly, do you think the on-disk format needs to compatible with a C++ struct so that we can cast that memory buffer to the struct? That may be super-fast but that also comes with many limitations. It's hard to extend, for example. Every time we want to store variable-length objects we need to define string-table-like data structure. And I'm not very sure that it's fastest -- because mmap'able objects are not very compact on disk, slow disk IO could be a bottleneck, if we compare that with more compact file format. I believe Protobufs or Thrust are fast enough or even might be faster.</div><div><br></div><div>Secondly, do you know why we are dumping post-linked object file to Native format? If we want to have a different kind of *object* file format, we would want to have a tool to convert an object file in an existing file format (say, ELF) to "native", and teach LLD how read from the file. Currently we are writing a file in the middle of linking process, which doesn't make sense to me.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 6, 2015 at 5:02 PM, Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, Feb 6, 2015 at 2:54 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br>
> Can we remove Native format support? I'd like to get input from anyone who<br>
> wants to keep the current Native format in LLD.<br>
<br>
</span>One of the original goals for LLD was to provide a new object file<br>
format for performance. The reason it is not used currently is because<br>
we've yet to teach llvm to generate it, and we haven't done that<br>
because it hasn't been finalized yet. The value it currently provides<br>
is catching stuff like this, so we can fix it now instead of down the<br>
road when we actually productize the native format.<br>
<br>
As for the specific implementation of the native format, I'm open to<br>
an extensible format, but only if the performance cost is low.<br>
<span><font color="#888888"><br>
- Michael Spencer<br>
</font></span><div><div><br>
><br>
> On Thu, Feb 5, 2015 at 2:03 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>><br>
> wrote:<br>
>><br>
>> The only way currently is to create a new reference, unless we can think<br>
>> 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<br>
>> to store information that is target specific.<br>
>><br>
>> Shankar Easwaran<br>
>><br>
>><br>
>> On 2/5/2015 2:22 PM, Simon Atanasyan wrote:<br>
>>><br>
>>> 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<br>
>>> specific<br>
>>> data over Native/YAML conversion barrier.<br>
>>><br>
>>> In this ABI relocation record r_info field in fact consists of five<br>
>>> 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<br>
>>> uses<br>
>>> an addendum from the relocation record. Each subsequent relocation takes<br>
>>> 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<br>
>>> can<br>
>>> set an AbsoluteAtom created for the "_gp" as the reference's target. But<br>
>>> what<br>
>>> about RSS_GP0 and RSS_LOC? I am considering the following approaches but<br>
>>> 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<br>
>>> 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>
>><br>
>><br>
>> --<br>
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted<br>
>> by the Linux Foundation<br>
>><br>
><br>
><br>
</div></div><div><div>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
</div></div></blockquote></div><br></div></div>