[llvm-dev] [Hexagon] Failure to disassemble some new-value instructions

[Bruce Hoult via llvm-dev]

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>