@@ -435,6 +435,32 @@ static std::vector<SharedSymbol<ELFT> *> getSymbolsAt(SharedSymbol<ELFT> *SS) {
435
435
}
436
436
437
437
// 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.
438
464
template <class ELFT > static void addCopyRelSymbol (SharedSymbol<ELFT> *SS) {
439
465
typedef typename ELFT::uint uintX_t;
440
466
0 commit comments