Skip to content

Commit a809158

Browse files
committedFeb 19, 2017
Add a comment about the copy relocation.
llvm-svn: 295622
1 parent caf810e commit a809158

File tree

2 files changed

+27
-0
lines changed

2 files changed

+27
-0
lines changed
 

‎lld/ELF/EhFrame.cpp

+1
Original file line numberDiff line numberDiff line change
@@ -62,6 +62,7 @@ template <class ELFT>
6262
size_t elf::readEhRecordSize(InputSectionBase<ELFT> *S, size_t Off) {
6363
return EhReader<ELFT>(S, S->Data.slice(Off)).readEhRecordSize();
6464
}
65+
6566
// .eh_frame section is a sequence of records. Each record starts with
6667
// a 4 byte length field. This function reads the length.
6768
template <class ELFT> size_t EhReader<ELFT>::readEhRecordSize() {

‎lld/ELF/Relocations.cpp

+26
Original file line numberDiff line numberDiff line change
@@ -435,6 +435,32 @@ static std::vector<SharedSymbol<ELFT> *> getSymbolsAt(SharedSymbol<ELFT> *SS) {
435435
}
436436

437437
// Reserve space in .bss or .bss.rel.ro for copy relocation.
438+
//
439+
// The copy relocation is pretty much a hack. If you use a copy relocation
440+
// in your program, not only the symbol name but the symbol's size, RW/RO
441+
// bit and alignment become part of the ABI. In addition to that, if the
442+
// symbol has aliases, the aliases become part of the ABI. That's subtle,
443+
// but if you violate that implicit ABI, that can cause very counter-
444+
// intuitive consequences.
445+
//
446+
// So, what is the copy relocation? It's for linking non-position
447+
// independent code to DSOs. In an ideal world, all references to data
448+
// exported by DSOs should go indirectly through GOT. But if object files
449+
// are compiled as non-PIC, all data references are direct. There is no
450+
// way for the linker to transform the code to use GOT, as machine
451+
// instructions are already set in stone in object files. This is where
452+
// the copy relocation takes a role.
453+
//
454+
// A copy relocation instructs the dynamic linker to copy data from a DSO
455+
// to a specified address (which is usually in .bss) at load-time. If the
456+
// static linker (that's us) finds a direct data reference to a DSO
457+
// symbol, it creates a copy relocation, so that the symbol can be
458+
// resolved as if it were in .bss rather than in a DSO.
459+
//
460+
// As you can see in this function, we create a copy relocation for the
461+
// dynamic linker, and the relocation contains not only symbol name but
462+
// various other informtion about the symbol. So, such attributes become a
463+
// part of the ABI.
438464
template <class ELFT> static void addCopyRelSymbol(SharedSymbol<ELFT> *SS) {
439465
typedef typename ELFT::uint uintX_t;
440466

0 commit comments

Comments
 (0)
Please sign in to comment.