[lld] r262590 - [ELF] - add support for relocations against local symbols when producing relocatable output.

George Rimar via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 3 22:31:38 PST 2016


>> +        // That can happen if creating relocatable output.
>> +        if (Sym.getType() == STT_SECTION)
>> +          SymName = Section->getSectionName();
>
>This seems wrong. There no requirement on the symbol name. Why not use
>the actual symbol name?

At that point SymName is empty. After the proper section name is assigned.
I did it to produce nice output that equals to gold now.
(Consider the source files from testcase of this patch are used):

Relocation section '.rela.eh_frame' at offset 0xa0 contains 3 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000020  000100000002 R_X86_64_PC32     0000000000000000 foo1 + 0
000000000034  000200000002 R_X86_64_PC32     0000000000000000 bar1 + 0
000000000048  000300000002 R_X86_64_PC32     0000000000000000 dah1 + 0

Symbol table '.symtab' contains 5 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 SECTION LOCAL  DEFAULT    3 
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    4 
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    5 
     4: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT    1 _start

Without that lines of code you would not see "foo1 + 0", but only " + 0".

>> +  // Local symbol -> ID, filled only when producing relocatable output.
>> +  llvm::DenseMap<const Elf_Sym *, uint32_t> Locals;
>> +
>
>You can just map input to output id using a std::vector, no?

In theory yes. But I was need to get symbol ID by its pointer. So if I would use vector
that would be O(N) complexity for search while map should be O(logN). 
Not that much difference probably but still something.

George.


More information about the llvm-commits mailing list