[lld] registry design proposal

[Nick Kledzik]

On Dec 4, 2013, at 3:10 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:

> 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 ?
Yes.

> 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 ?
Ah.  I see.  For mach-o I was just planning on registering one mach-o object file parser.  But if for ELF you want to register different parsers for x86 vx x86_64, then in the case that there is no command line option specifying the arch so you need to look at the first file, I would say you could add a static  method to ELFFile which returns the arch for a file.  Or you could always register all parsers and look at the arch of the returned file.

> 
>>> 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.
It is odd to have an object file parsed into different Atoms depending on some command line option.  You could have the parser always just return the string section as one big atom and have a pass with transforms the big atom into lots of little atoms (and fixes up references).  Or have the parser also break into little string atoms, but only coalesce them if -merge-strings is used.

> 
> 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 ?
A free form dictionary would work.  It is a common technique in scripting languages, but less so in C++. As I mentioned a while back the darwin linker has a struct of options for the reader.  The struct has options about how to handle dwarf unwind vs compact unwind.  So, yes, I see the need for this sort of info.  Another way to do this might be that at registration time you can pass some options for the parser class.


-Nick