[LLVMdev] relocation visitor

Nick Lewycky nlewycky at google.com
Fri Sep 21 16:06:39 PDT 2012


Currently llvm-dwarfdump isn't very useful on ELF .o files because it
doesn't apply relocations.

nlewycky at ducttape:~$ llvm-dwarfdump helloworld.o | grep debug_str\\[
0x0000000c:   DW_AT_producer [DW_FORM_strp]     ( .debug_str[0x00000000] =
"clang version 3.2 (trunk 163034)")
0x00000012:   DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang
version 3.2 (trunk 163034)")
0x00000022:   DW_AT_comp_dir [DW_FORM_strp]     ( .debug_str[0x00000000] =
"clang version 3.2 (trunk 163034)")
0x00000027:     DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00000000] =
"clang version 3.2 (trunk 163034)")
0x00000044:       DW_AT_name [DW_FORM_strp]     ( .debug_str[0x00000000] =
"clang version 3.2 (trunk 163034)")
0x00000052:       DW_AT_name [DW_FORM_strp]     ( .debug_str[0x00000000] =
"clang version 3.2 (trunk 163034)")
0x00000061:     DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00000000] =
"clang version 3.2 (trunk 163034)")
0x00000068:     DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00000000] =
"clang version 3.2 (trunk 163034)")

The attached patch fixes the problem for ELF X86-64 files:

nlewycky at ducttape:~$ llvm-dwarfdump helloworld.o | grep debug_str\\[
0x0000000c:   DW_AT_producer [DW_FORM_strp]     ( .debug_str[0x00000000] =
"clang version 3.2 (trunk 163034)")
0x00000012:   DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000021] =
"helloworld.c")
0x00000022:   DW_AT_comp_dir [DW_FORM_strp]     ( .debug_str[0x0000002e] =
"/home/nlewycky")
0x00000027:     DW_AT_name [DW_FORM_strp]       ( .debug_str[0x0000003d] =
"main")
0x00000044:       DW_AT_name [DW_FORM_strp]     ( .debug_str[0x00000046] =
"argc")
0x00000052:       DW_AT_name [DW_FORM_strp]     ( .debug_str[0x0000004b] =
"argv")
0x00000061:     DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00000042] =
"int")
0x00000068:     DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00000050] =
"char")

but I'm not asking you to review the patch, that's why I'm posting to
llvm-dev. I'm asking for design review.

This patch introduces "RelocationVisitor", a new templated class that tries
to safe the user of relocations some work by breaking down relocations into
their basic mathematical operations. If you look at the ELF x86-64 spec,
you'll note that it defines things like:
 A = the addend field of the relocation
 B = base address which the shared object has been loaded into
 P = address of the storage being relocated
 S = value of the symbol whose index resides in the relocation entry
and then the relocations are
  R_X86_64_64: S + A
  R_X86_64_PC32: S + A - P
so my thinking was that a client class could define functions that provide
values for A,B,P,S,etc., and then we break down visiting a relocations down
to calls to those functions. Those which really can't be implemented
generically (IRELATIVE?) should be pure virtual in the RelocationVisitor
and force the subclasses to implement their own.

The visitor could then build up an exact integer if it knows all the
relevant facts (has a concrete integer for the address of symbols, etc.),
or it could build up an MCExpr, or it could build up a ConstantExpr, etc.

The attached patch shows the concept with just 5 simple relocations from
ELF X86-64, but I've been looking at MachO and other ELF architectures, and
I think the concept will pan out. I'm a bit out of water here, so I'd
appreciate any other file format experts taking a look and letting me know
what you think.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120921/56874264/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reloc-visitor-design.patch
Type: application/octet-stream
Size: 7785 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120921/56874264/attachment.obj>


More information about the llvm-dev mailing list