[PATCH] D15965: Add support for dumping relocations in non-relocatable files

Rafael Ávila de Espíndola via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 28 12:45:01 PDT 2016


rafael added a comment.

This is much better, but needs a bit more work.


================
Comment at: include/llvm/Object/ELFObjectFile.h:687
@@ +686,3 @@
+bool ELFObjectFile<ELFT>::getRelocationIsDynamic(DataRefImpl Rel) const {
+  return Rel.d.b & 1;
+}
----------------
It is undesirable to expose this.

Calling a relocation "dynamic" was a hack to avoid looking at sh_link every time one asks for a symbol for a relocation. I removed the hack in r264624.


================
Comment at: test/tools/llvm-objdump/X86/relocations-in-nonrelocatable.test:7
@@ +6,3 @@
+// int main(void) { g(); };
+// gcc main.c -o main -Wl,--emit-relocs
+
----------------
You can produce a much simpler file by running

gcc -c main.c -fno-asynchronous-unwind-tables -fPIC
ld.gold main.o -o main.so -shared --emit-relocs

Please do that and also run "llvm-readobj -r" so show all the relocations in the file.

I investigated a bit exactly which relocations are printed by bfd objdump. The answer is that it prints relocations from sections that use .symtab as the symbol table. That is just a limitation of bfd.

Some options we have given the desire to print relocations in executables and shared libraries.

* Add a check for just the restriction that bfd has. That seems a bit too much of a bug for bug compatibility.
* Print any relocation in section that have a relocated section (sh_info is not zero). Unlike bfd this would print the info for .rela.plt.
* Print all relocations. Unlike bfd this would print .rela.plt and .rela.dyn.

================
Comment at: tools/llvm-objdump/llvm-objdump.cpp:444
@@ -444,16 +443,3 @@
   StringRef Target;
-  if (symb->getType() == ELF::STT_SECTION) {
-    ErrorOr<section_iterator> SymSI = SI->getSection();
-    if (std::error_code EC = SymSI.getError())
-      return EC;
-    const Elf_Shdr *SymSec = Obj->getSection((*SymSI)->getRawDataRefImpl());
-    ErrorOr<StringRef> SecName = EF.getSectionName(SymSec);
-    if (std::error_code EC = SecName.getError())
-      return EC;
-    Target = *SecName;
-  } else {
-    ErrorOr<StringRef> SymName = symb->getName(StrTab);
-    if (!SymName)
-      return SymName.getError();
-    Target = *SymName;
-  }
+  if (SI != Obj->symbol_end()) {
+    const Elf_Sym *symb = Obj->getSymbol(SI->getRawDataRefImpl());
----------------
This is guarding against a relocation with a symbol index of 0? That is an independent change, no?

================
Comment at: tools/llvm-objdump/llvm-objdump.cpp:445
@@ +444,3 @@
+  if (SI != Obj->symbol_end()) {
+    const Elf_Sym *symb = Obj->getSymbol(SI->getRawDataRefImpl());
+    if (symb->getType() == ELF::STT_SECTION) {
----------------
Since moving it, please use the new variable name style: Symb

================
Comment at: tools/llvm-objdump/llvm-objdump.cpp:462
@@ -460,1 +461,3 @@
+  } else
+    Target = "*ABS*";
   switch (EF.getHeader()->e_machine) {
----------------
Does gnu objdump print ABS for this? Seems like an odd term. ABS refers to symbols, but in here you have no symbol at all.

================
Comment at: tools/llvm-objdump/llvm-objdump.cpp:1195
@@ -1195,1 +1194,3 @@
 
+  std::map <uint64_t, SectionRef> SectionAddress;
+  for (section_iterator i (Obj->section_begin()), n (Obj->section_end()); i != n; ++i)
----------------
You only need a sorted std::vector, no?

================
Comment at: tools/llvm-objdump/llvm-objdump.cpp:1196
@@ +1195,3 @@
+  std::map <uint64_t, SectionRef> SectionAddress;
+  for (section_iterator i (Obj->section_begin()), n (Obj->section_end()); i != n; ++i)
+    SectionAddress [i->getAddress()] = *i;
----------------
Initialize the iterators with "I = " not "I(...)";

================
Comment at: tools/llvm-objdump/llvm-objdump.cpp:1221
@@ +1220,3 @@
+          continue;
+        --BoundingSection;
+        if ((BoundingSection->first + BoundingSection->second.getSize()) < Address)
----------------
Can you use lower_bound?


http://reviews.llvm.org/D15965





More information about the llvm-commits mailing list