Currently llvm-dwarfdump isn't very useful on ELF .o files because it doesn't apply relocations.<div><br></div><div><div>nlewycky@ducttape:~$ llvm-dwarfdump helloworld.o | grep debug_str\\[</div><div>0x0000000c:   DW_AT_producer [DW_FORM_strp]     ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)")</div>

<div>0x00000012:   DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)")</div><div>0x00000022:   DW_AT_comp_dir [DW_FORM_strp]     ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)")</div>

<div>0x00000027:     DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)")</div><div>0x00000044:       DW_AT_name [DW_FORM_strp]     ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)")</div>

<div>0x00000052:       DW_AT_name [DW_FORM_strp]     ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)")</div><div>0x00000061:     DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)")</div>

<div>0x00000068:     DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)")</div></div><div><br></div><div>The attached patch fixes the problem for ELF X86-64 files:</div>

<div><br></div><div><div>nlewycky@ducttape:~$ llvm-dwarfdump helloworld.o | grep debug_str\\[</div><div>0x0000000c:   DW_AT_producer [DW_FORM_strp]     ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)")</div>

<div>0x00000012:   DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000021] = "helloworld.c")</div><div>0x00000022:   DW_AT_comp_dir [DW_FORM_strp]     ( .debug_str[0x0000002e] = "/home/nlewycky")</div><div>

0x00000027:     DW_AT_name [DW_FORM_strp]       ( .debug_str[0x0000003d] = "main")</div><div>0x00000044:       DW_AT_name [DW_FORM_strp]     ( .debug_str[0x00000046] = "argc")</div><div>0x00000052:       DW_AT_name [DW_FORM_strp]     ( .debug_str[0x0000004b] = "argv")</div>

<div>0x00000061:     DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00000042] = "int")</div><div>0x00000068:     DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00000050] = "char")</div></div><div><br>
</div>
<div>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.</div><div><br></div><div>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:</div>

<div> A = the addend field of the relocation</div><div> B = base address which the shared object has been loaded into</div><div> P = address of the storage being relocated</div><div> S = value of the symbol whose index resides in the relocation entry</div>

<div>and then the relocations are</div><div>  R_X86_64_64: S + A</div><div>  R_X86_64_PC32: S + A - P</div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>Nick</div><div><br></div><div><br></div><div><br></div>