This is an archive of the discontinued LLVM Phabricator instance.

[ELF] Allow customization of OutputELFWriter class
AbandonedPublic

Authored by atanasyan on Apr 7 2015, 4:13 PM.

Details

Summary

Now target specific code inherits writer classes from ExecutableWriter and DynamicLibraryWriter. It is OK unitil we need to add some target specific functionality which is common to both executable and dynamic library writers. We have to either duplicate such code or move it to utility routine.

The patch tries to solve this problem using some sort of template trick. Both ExecutableWriter and DynamicLibraryWriter classes get one more template argument BaseWriter and use it as a base class. By default this argument has OutputELFWriter<ELFT> so we get the same code as now. If we need to share some code amont executable and dynamic library writers we create new class (for example MipsOutputWriter) inherited from OutputWriter and put common code to this class. Then we create writer as in example below:

template <class ELFT>
class MipsExecutableWriter
    : public ExecutableWriter<ELFT, MipsOutputWriter<ELFT>> {
...
};

template <class ELFT>
using MipsDynamicLibraryWriter =
    DynamicLibraryWriter<ELFT, MipsOutputWriter<ELFT>>;

The patch makes some part of code more complicated but reduces code size and prevent code duplication.

Any objections and / or comments?

Diff Detail

Repository
rL LLVM

Event Timeline

atanasyan updated this revision to Diff 23378.Apr 7 2015, 4:13 PM
atanasyan retitled this revision from to [ELF] Allow customization of OutputELFWriter class.
atanasyan updated this object.
atanasyan edited the test plan for this revision. (Show Details)
atanasyan set the repository for this revision to rL LLVM.
atanasyan added a project: lld.
atanasyan added a subscriber: Unknown Object (MLST).
ruiu accepted this revision.Apr 7 2015, 4:42 PM
ruiu edited edge metadata.

Hm. So this patch apparently solves the issue you described but with a (non-obvious) template magic to insert a class to a class hierarchy. This complexity made me a bit nervous, so I thought about alternatives for a while.

The first thing that came up to my mind is to use utility functions you described, but with that you cannot purge duplicates. The other way would be to use multiple inheritance, but that's worse than the template magic. After all, this patch removes 170 lines, so maybe it's a good hack.

This revision is now accepted and ready to land.Apr 7 2015, 4:42 PM

Prior to this change, the target executable writer's used to contain the TargetLinkingContexts and their TargetLayout's. The Target writers do a static cast and return their layout's which i feel is not a nice design, IMO. I think you could safely derive from OutputELFWriter and create MipsOutputELFWriter. This would save the same amount of duplicated code too. Thoughts ?

You could have a helper class that contains common code that the MIPS executable / dynamic writer can.contain? No?? This was how it used to be right?

I don't prefer the design here especially the static casts.

You could have a helper class that contains common code that the MIPS executable / dynamic writer can.contain? No?? This was how it used to be right?

This approach is not so bad and used right now. Both MipsDynamicLibraryWriter and MipsExecutableWriter contains an instance of MipsELFWriter which provides helper methods. But I am annoyed a bit that almost all methods of MipsXXXWriter classes just call the same methods of MipsELFWriter class. Besides that it would be nice to escape code duplication in methods like MipsXXXWriter::createSymbolTable(), MipsXXXWriter::createDynamicTable() etc. But if I pass this code to the MipsELFWriter class I in fact increase number of code lines.

By the way, why don't you use a helper class to keep common code used by HexagonXXXWriter classes in the single place? As far as I can see such code has been spread among HexagonLinkingContext.h and HexagonTargetHandler.h since rL233718.

I do plan to clean those up in future. It's currently a very rudimentary solution.

ruiu added a comment.Apr 8 2015, 8:41 AM

This is a bit tricky, but I don't think this is a bad solution. I'd support
this patch. The other way would be to use multiple inheritance to mix-in
architecture-specific member functions to the writers, but that's what I
really don't want to see.

atanasyan abandoned this revision.Dec 19 2015, 12:25 PM
lib/ReaderWriter/ELF/X86/X86DynamicLibraryWriter.h