[llvm-commits] PATCH: lld ReaderELF.cpp update

Nick Kledzik kledzik at apple.com
Mon Jul 23 13:04:40 PDT 2012


On Jul 20, 2012, at 9:52 AM, Sid Manning wrote:
> If this patch is ok then it seems to me that the next logical thing to work on would be the ELFWriter.  Along those lines I've started looking at the Mach-O writer as my guide. The writer portion is more complex than the reader and I think that making interim drops will be helpful so that you guys and others keep tabs on the direction and coding decisions being made.
> 
> In looking at, WriterMachO.cpp the first thing I noticed was it depended on FileOutputBuffer but there is a patch out there for it so I will pull that in and see how it works.
> 
> A range of different processors will use ELF each with their own set of relocation types.  Is my reading of the code correct that SectionChunk::write's applyFixup call where the target specific relocs will be handled?  That will be nice if that works that way.
MachO is similar to ELF in that the same format supports multiple processors/architectures.  What I did for mach-o was to factor out the architecture specific handling to an abstract class with virtual methods, then implement concrete subclass for each architecture.  Given that ELF is used across not just with many processors, but across many OSs.  I think the ELF Writer will be doing a lot of that sort of factoring (for instance per-OS magic sections).  So the first step of the ELF Writer will be to analyze the WriterOptionsELF object and use that information to configure the correct set of helper objects for the main WriterELF object.

Another difference between mach-o and ELF is that ELF can probably use the existing relocation type numbers for its Reference.kind values.  In mach-o relocations, there is only 4-bits for the relocation type, and there are often "pairs" of relocations.  Rather than carry this complexity through the linker, I decided to create new mach-o Reference.kind values and have the mach-o Reader transform the mach-o file format relocations into simpler internal References.

-Nick



More information about the llvm-commits mailing list