<div style="font-family: arial, helvetica, sans-serif"><font size="2"><br><br><div class="gmail_quote">On Fri, Jun 22, 2012 at 11:49 PM, Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Jun 22, 2012 at 3:11 AM, Alexey Samsonov <<a href="mailto:samsonov@google.com">samsonov@google.com</a>> wrote:<br>

> Hi!<br>
><br>
> libObject seems to incorrectly implement<br>
> ELFObjectFile::getSymbolAddress. See this reproducer:<br>
> $ cat main.cc<br>
> int main() {<br>
>   return 0;<br>
> }<br>
> $ g++ main.cc -o main.out<br>
> $ nm main.out | grep main<br>
>                  U __libc_start_main@@GLIBC_2.2.5<br>
> 00000000004004b4 T main<br>
> $ llvm-nm main.out | grep main<br>
>          U __libc_start_main@@GLIBC_2.2.5<br>
> 00800884 T main<br>
><br>
> Let's try to get what's wrong:<br>
> 800884 - 4004b4 = 4003d0<br>
> $ objdump -h main.out | grep .text<br>
>  11 .text         000001c8  00000000004003d0  00000000004003d0  000003d0<br>
>  2**4<br>
><br>
> So, the symbol address is incorrectly incremented by the section offset. To<br>
> my understanding, attached patch should be applied to fix this. Please check<br>
> if this is ok to apply.<br>
> getSymbolFileOffset in the same file seems to be fine, at least according to<br>
> this quote from ELF specs:<br>
><br>
> Symbol table entries for different object file types have slightly different<br>
> interpretations for the st_value member.<br>
> <...><br>
> * In relocatable files, st_value holds a section offset for a defined<br>
> symbol. That is, st_value is an offset from the beginning of the section<br>
> that st_shndx identifies.<br>
> * In executable and shared object files, st_value holds a virtual address.<br>
> [...]<br>
><br>
> --<br>
> Alexey Samsonov, MSK<br>
><br>
<br>
</div></div>I agree that llvm-nm is incorrect here, but I'm not sure this is the<br>
correct fix. The issue is that exactly what getSymbolAddress is<br>
supposed to return is undocumented. There was quite a bit of<br>
discussion about it in "[llvm-commits] MachOObjectFile fix functions",<br>
but even after reading it I'm not 100% sure what it should do.  This<br>
patch also doesn't seem to handle the difference between a relocatable<br>
file and an executable.<br></blockquote><div><br></div><div>True. How can I easily distinguish between relocatable files and executables?</div><div>Is it a bad idea to provide two different methods for different types of files?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've CCed the people from the above thread. I would like to decide on<br>
a well defined meaning for all of the Address/Offset functions and<br>
document that in the code before we change anything, as I believe the<br>
ELF MCJIT is relying on the current behavior.</blockquote><div><br></div><div>Yes, I would really like the behavior to be documented, as it's a bit confusing</div><div>that system nm and "objdump -t" provide different results than "llvm-nm"</div>
<div>and "llvm-objdump -t". </div><div><br></div><div>What I was actually trying to achieve is to</div><div>to symbolize a given instruction address - get the name of function that contains</div><div>this instruction. I thought that the easy and straightforward way to do this is to</div>
<div>use libLLVMObject, iterate over all symbols from symbol table in executable, get symbol name and size</div><div>and do a simple check. Well, it doesn't work this way :)</div></div><div><br></div>--<br><div>Alexey Samsonov, MSK</div>

</font></div>