thr3ads.net - llvm dev - [LLVMdev] possible bug in COFFObjectFile::getSymbolType() [Oct 2014]

If this information is useful, please help other people find it:
Share via:

Ted Woodward

2014-Aug-26 23:12 UTC

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

The section is .text, so I assume it’s got IMAGE_SCM_CNT_CODE set. The problem
is the symbol is marked (read & execute), but the test is (read &
!write), so the symbol gets marked as ST_Data instead of ST_Other.

From: David Majnemer [mailto:david.majnemer at gmail.com] 
Sent: Friday, August 22, 2014 5:44 PM
To: Ted Woodward
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] possible bug in COFFObjectFile::getSymbolType()

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/20140826/dc30c6f8/attachment.html>

David Majnemer

2014-Oct-31 05:23 UTC

head link

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

I believe this is fixed in r220952.

On Tue, Aug 26, 2014 at 4:12 PM, Ted Woodward <ted.woodward at
codeaurora.org>
wrote:
> The section is .text, so I assume it’s got IMAGE_SCM_CNT_CODE set. The
> problem is the symbol is marked (read & execute), but the test is (read
&
> !write), so the symbol gets marked as ST_Data instead of ST_Other.
>
>
>
> *From:* David Majnemer [mailto:david.majnemer at gmail.com]
> *Sent:* Friday, August 22, 2014 5:44 PM
> *To:* Ted Woodward
> *Cc:* LLVM Developers Mailing List
> *Subject:* Re: [LLVMdev] possible bug in COFFObjectFile::getSymbolType()
>
>
>
> 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/20141030/4c01ff44/attachment.html>

Ted Woodward

2014-Nov-26 21:50 UTC

head link

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

Hi David,

 

I apologize for taking this long to reply. I’ve been on vacation.

 

We’ve tested r220952, and it fixes the issue we saw with COFF symbol types.
Thanks!

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

 

From: David Majnemer [mailto:david.majnemer at gmail.com] 
Sent: Friday, October 31, 2014 12:24 AM
To: Ted Woodward
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] possible bug in COFFObjectFile::getSymbolType()

 

I believe this is fixed in r220952.

 

On Tue, Aug 26, 2014 at 4:12 PM, Ted Woodward <ted.woodward at codeaurora.org
<mailto:ted.woodward at codeaurora.org> > wrote:

The section is .text, so I assume it’s got IMAGE_SCM_CNT_CODE set. The problem
is the symbol is marked (read & execute), but the test is (read &
!write), so the symbol gets marked as ST_Data instead of ST_Other.

 

From: David Majnemer [mailto:david.majnemer at gmail.com
<mailto:david.majnemer at gmail.com> ]
Sent: Friday, August 22, 2014 5:44 PM
To: Ted Woodward
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] possible bug in COFFObjectFile::getSymbolType()

 

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
<mailto: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 <mailto: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/20141126/f686fd07/attachment.html>

llvm dev - Oct 2014 - [LLVMdev] possible bug in COFFObjectFile::getSymbolType()

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

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

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