[lld] registry design proposal

[Shankar Easwaran]

On 12/4/2013 4:31 PM, Nick Kledzik wrote:
> On Dec 4, 2013, at 9:56 AM, Shankar Easwaran <shankare at codeaurora.org> wrote:
>
>>>   1) LinkingContext has a bunch of oddball methods that have just been added because it was convenient (such as getDefaultHandler which is really only needed by the Archive Reader).
>> Gnu flavor has a lot of targets(X86_64, Hexagon, ARM, MIPS) and so on, it would not be possible to have a Generic Reader that encompasses all the issues. Currently we have the ELFTargetHandler, which is really flaky and is not really flexible enough to handle ARM, Hexagon in a sane way.
>>
>> Targets may use LinkingContext to really get to the DefaultReader thats applicable for that target.
>>
>> I am not sure if the new design addresses this.
> The design gets rid of the Reader class. But does not do anything to help or hinder ELF’s need for architecture specific parsing.  You can continue to use the delegate object (TargetHandler), but you may need to hang it off the ELFFile object being created instead of hanging it off the LinkingContext.
I was thinking of subclassing the Readers so that each 
architecture/target can own Readers and create Atoms. I would like to 
remove TargetHandler completely because its very flaky.

Does each target/architecture register their parsers from the Driver 
then ? since Readers would be gone now ?

If each target/architecture  tries to register its own parser, we would 
hit a chicken/egg problem when trying to determine the file type of the 
first Input from the InputRegistry ?

Whats the best way to design this ?

>>> 2) The native file format does not record the “universe” for the kind field of References.  That is, a mach-o file could be converted to native and an ELF file converted to native and both may have a reference of kind 42, but the same 42 has different semantics.
>> Does having a separate magic for the native file format to encompass different architectures solve this issue ?
> No.  Image an x86 mach-o file converted to native and an x86 ELF file converted to native.  The are both the same arch, but Reference kind values have different semantics.
Ah okay.
>
>>> 3) identify_magic() is called redundantly in lots of places.
>> The Driver needs to know the correct node type that needs to be created for a input file, for example on ELF, we have a mix of object files and libraries(the libraries can refer to linker scripts!, for example libc.so which is a linker script). I assume Mach-O also would need this information to group nodes properly.
>>
>> I am not sure if the new design addresses this.
>>
>> Driver would need to call identify_magic (or) some equivalent to decide what kind of node that needs to be created.
> Can the File object be created first, and then use file->kind() to see if it is an object, archive, or shared library?
Currently a File is obtained only as a result of using parseFile, and is 
threaded so that they all parse the file at once.

If we need a File to be created we need an API to InputRegistry to just 
return a light File object that can be used to query ?
>> b) Is there a linkingContext thats associated with the InputParserRegistry ? If there is none, how does parseFile convey that info to the Reader ?
> Hopefully, parsing no longer requires a linkingContext.
It looks like ELF also is requiring the LinkingContext. The only use of 
LinkingContext is to look at some options (-merge-strings) which divides 
up the section containing strings into atoms with mergeByContent.

Any ideas here ? One idea that is possible is if parseFile be changed so 
that it can be called with a map containing options(std::map<StringRef, 
StringRef>) that might be of use to the Parser ?

Thanks

Shankar Easwaran

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