[LLVMdev] ELFObjectFile changes, llvm-objdump showing 'wrong' values?

Bendersky, Eli eli.bendersky at intel.com
Sun Jan 22 22:26:08 PST 2012


Hi,

I would like to examine the implications you mention in more detail.

(1) Symbol address
According to the ELF standard, in a symbol table entry st_value means: "In relocatable files, st_value holds a section offset for a defined symbol. That is,
st_value is an offset from the beginning of the section that st_shndx identifies." (*)

Therefore, when queried about a symbol's address what would the right answer be? In ELFObjectFile::getSymbolAddress, previously, it was simply symb->st_value (which is the relative offset to the section). Now, Section->sh_addr is added to reflect the actual address of the symbol. 

Ignoring for the moment the change this imposes on objdump & nm (which can be amended), what would the expected address be for clients of getSymbolAddress?

(2) Symbol offset
Again, referring to the definition of the "st_value" field above, the file offset of the symbol is the section offset plus the symbol's offset in the section, which is reflected in the new code:

    Result = symb->st_value +
             (Section ? Section->sh_offset : 0);

The old code subtracted Section->sh_addr from that for reasons that are not entirely clear to me.

I'm not sure where this creates a problem for you? AFAICS, neither llvm-objdump nor llvm-nm use the symbol's file offset. It's also not clear from your pastes of llvm-objdump and objdump what the significant difference are.

Eli

(*) ELFObjectFile represents a relocatable file


> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Will Dietz
> Sent: Monday, January 23, 2012 07:32
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] ELFObjectFile changes, llvm-objdump showing 'wrong'
> values?
> 
> Hi all,
> 
> I'm using the MC framework for a project, and while updating to latest trunk
> (r148672) encountered the following issue:
> 
> It seems that SymbolRef::getAddress and SymbolRef::getFileOffset have
> been changed to add the symbol's offset to the offset of the containing
> section?
> 
> This has the following implications:
> 
> To get the /actual/ fileoffset, I now need to do:
> Symbol.getFileOffset() - ContainingSection.getFileOffset() And to get the
> address relative to the section, I do:
> Symbol.getFileOffset() - 2*ContainingSection.getFileOffset()
> 
> I suspect this isn't the desired functionality (what use is the original value?)?
> 
> You can also see the impact of this on the tool llvm-objdump (as well as llvm-
> nm), as shown below:
> 
> Normal objdump: http://pastebin.com/Fsv3Vvye vs llvm-objdump:
> http://pastebin.com/MRryQe4D
> 
> I believe r148653 caused this, but haven't verified directly.  This didn't happen
> as of r148100.
> 
> Am I missing something (my code borrows a good deal from llvm-objdump
> and llvm-nm, so if they are doing something wrong with respect to these
> new changes, so am I), or is this something that should be fixed?
> 
> Thanks for your time!
> 
> ~Will
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.




More information about the llvm-dev mailing list