Ralf-Philipp Weinmann via llvm-dev
2016-Feb-01 14:00 UTC
[llvm-dev] [Hexagon] Failure to disassemble some new-value instructions
Dear list, I noticed that the Hexagon disassembler has issues with disassembling some firmwares I have. When tracing one of these problems, the handling of some new-value instructions in HexagonDisassembler::getSingleInstruction() turned out to be the cause, specifically this statement: [lines 384-386 in HexagonDisassembler.cpp in HEAD] else if (SubregBit) // Subreg bit should not be set for non-doublevector newvalue producers return MCDisassembler::Fail; Where does the requirement come from? Maybe I overlooked it, but I do not see it in the Hexagon V5/V55 Programmer’s Reference Manual. One instruction packet I have encountered in the wild that triggers this failure is: 10: e0 7e df 78 78df7ee0 { r0 = #-9 14: 01 40 91 91 91914001 r1 = memw(r17 + #0) 18: 10 e1 03 25 2503e110 if (cmp.gtu(r1.new, #1)) jump:t 0x30 } Removing the requirement seems to work fine (see attached patch). Cheers, Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: hexagon-new-value.patch Type: application/octet-stream Size: 810 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160201/2e3ed60a/attachment.obj>
Colin LeMahieu via llvm-dev
2016-Feb-01 18:24 UTC
[llvm-dev] [Hexagon] Failure to disassemble some new-value instructions
This looks similar to https://llvm.org/bugs/show_bug.cgi?id=25956, it looks like the instruction is encoded incorrectly, for instance if you re-assemble that packet that bit is not set. I added r259380 which points out the location in the manual which says this bit must be 0, 10.11 "Nt[0] is reserved and should always be encoded as zero". Your patch does work around the issue in the meantime. -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Ralf-Philipp Weinmann via llvm-dev Sent: Monday, February 01, 2016 8:00 AM To: llvm-dev at lists.llvm.org Subject: [llvm-dev] [Hexagon] Failure to disassemble some new-value instructions Dear list, I noticed that the Hexagon disassembler has issues with disassembling some firmwares I have. When tracing one of these problems, the handling of some new-value instructions in HexagonDisassembler::getSingleInstruction() turned out to be the cause, specifically this statement: [lines 384-386 in HexagonDisassembler.cpp in HEAD] else if (SubregBit) // Subreg bit should not be set for non-doublevector newvalue producers return MCDisassembler::Fail; Where does the requirement come from? Maybe I overlooked it, but I do not see it in the Hexagon V5/V55 Programmer’s Reference Manual. One instruction packet I have encountered in the wild that triggers this failure is: 10: e0 7e df 78 78df7ee0 { r0 = #-9 14: 01 40 91 91 91914001 r1 = memw(r17 + #0) 18: 10 e1 03 25 2503e110 if (cmp.gtu(r1.new, #1)) jump:t 0x30 } Removing the requirement seems to work fine (see attached patch). Cheers, Ralf
Bruce Hoult via llvm-dev
2016-Feb-02 11:16 UTC
[llvm-dev] [Hexagon] Failure to disassemble some new-value instructions
Such bits often become non-zero on later versions of the architecture. As Ralf says the code in question came from firmware, not from LLVM, it's entirely possible that it's a valid but undocumented instruction, and attempting to use re-assembled code with that bit forced to zero will not work. On Mon, Feb 1, 2016 at 9:24 PM, Colin LeMahieu via llvm-dev < llvm-dev at lists.llvm.org> wrote:> This looks similar to https://llvm.org/bugs/show_bug.cgi?id=25956, it > looks like the instruction is encoded incorrectly, for instance if you > re-assemble that packet that bit is not set. > > I added r259380 which points out the location in the manual which says > this bit must be 0, 10.11 "Nt[0] is reserved and should always be encoded > as zero". > > Your patch does work around the issue in the meantime. > > -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Ralf-Philipp Weinmann via llvm-dev > Sent: Monday, February 01, 2016 8:00 AM > To: llvm-dev at lists.llvm.org > Subject: [llvm-dev] [Hexagon] Failure to disassemble some new-value > instructions > > Dear list, > > I noticed that the Hexagon disassembler has issues with disassembling some > firmwares I have. When tracing one of these problems, the handling of some > new-value instructions in HexagonDisassembler::getSingleInstruction() > turned out to be the cause, specifically this statement: > > [lines 384-386 in HexagonDisassembler.cpp in HEAD] > else if (SubregBit) > // Subreg bit should not be set for non-doublevector newvalue > producers > return MCDisassembler::Fail; > > Where does the requirement come from? Maybe I overlooked it, but I do not > see it in the Hexagon V5/V55 Programmer’s Reference Manual. > > One instruction packet I have encountered in the wild that triggers this > failure is: > > 10: e0 7e df 78 78df7ee0 { r0 = #-9 > 14: 01 40 91 91 91914001 r1 = memw(r17 + #0) > 18: 10 e1 03 25 2503e110 if (cmp.gtu(r1.new, #1)) jump:t 0x30 } > > Removing the requirement seems to work fine (see attached patch). > > Cheers, > Ralf > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160202/b5b0d0e4/attachment.html>