[LLVMdev] possible bug in COFFObjectFile::getSymbolType()

[David Majnemer]

COFF sections also contain stuff like IMAGE_SCN_CNT_CODE and
IMAGE_SCN_CNT_INITIALIZED_DATA.  Are either of those set on the section in
question?

It may make more sense to try to key off of those section characteristics
as well.


On Fri, Aug 22, 2014 at 9:55 AM, Ted Woodward <ted.woodward at codeaurora.org>
wrote:

> I’m working on adding data detection to llvm-objdump, so it prints out raw
> data for symbols with type SymbolRef::ST_Data instead of disassembling
> them. This causes llvm/test/MC/ARM/Windows/mov32t-range.s to fail, because
> the symbol “truncation” comes back as SymbolRef::ST_Data, and the code gets
> dumped as bytes instead of disassembled.
>
>
>
> I traced the problem back to COFFObjectFile::getSymbolType() in
> llvm/lib/Object/COFFObjectFile.cpp :
>
>     if (Characteristics & COFF::IMAGE_SCN_MEM_READ &&
>
>         ~Characteristics & COFF::IMAGE_SCN_MEM_WRITE) // Read only.
>
>       Result = SymbolRef::ST_Data;
>
>
>
> I think it should also check for ~Characteristics &
> COFF::IMAGE_SCN_MEM_EXECUTE. The symbol, in this case, is READ, EXECUTE,
> !WRITE.
>
>
>
>     if (Characteristics & COFF::IMAGE_SCN_MEM_READ &&
>
>         ~Characteristics & COFF::IMAGE_SCN_MEM_WRITE &&
>
>         ~Characteristics & COFF::IMAGE_SCN_MEM_EXECUTE) // Read only, not
> execute.
>
>       Result = SymbolRef::ST_Data;
>
>
>
> I’m not very familiar with COFF; what ramifications would this change have?
>
>
>
> Ted
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/b27e75db/attachment.html>