[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