[llvm-dev] PPC64 Disassembler

Fri Dec 22 03:33:41 PST 2017

BC is flagged as isCodeGenOnly in the tablegen because of:

  // BCC represents an arbitrary conditional branch on a predicate.
  // FIXME: should be able to write a pattern for PPCcondbranch, but can't
use
  // a two-value operand where a dag node expects two operands. :(
  let isCodeGenOnly = 1 in {

IIRC isCodeGenOnly instructions have different disassembly behavior.  The
X86 backend has / had a "ForceDisassemble" flag with the comment

   // The disassembler should know about this, but not the asmparser.

The assembly input is handled via an instruction alias, which I think is
only used by the asmparser to expand bne into the isCodeGenOnly form:

defm : BranchExtendedMnemonic<"ne", 68>;

Someone else should know off the top of their head but the x86 backend has
a very similar setup (X86InstrControl.td) for the ICBr multiclass which
handles different bit widths of conditional branch immediates, and
isCodeGenOnly and ForceDisassemble are both set on two of the three forms.
That might explain why it works there and not with PPC, but I might be
wrong.

Hope that helps,
GNOMETOYS

On Fri, Dec 1, 2017 at 5:14 AM, Leonardo Bianconi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
>
>
> But where is the flat set? Maybe I can debug and check what is going on.
>
>  The MCInstrDesc are in a table in lib/Target/PowerPC/PPCGenInstrInfo.inc
> of your build directory.
>
> Some additional information:
>
> MCInst opcode: 0x7cb
>
> Decode Index: 0x1e
>
> I had assumed this would have dissembled to '// Inst #234 = BC' which does
> have the branch flag set, but I think that opcode is for XXLNOR instruction.
>
> Could it be disassembling to `// Inst #2014 = gBC` instead which does not
> have the branch flag set? Adding Hal and Ulrich in case they have some
> extra insight here.
>
> This code is new for me, I will make some more debugging to check this,
> and if I find more information, I let you know.
>
>
>
> Remembering I’m using a little endian Power8 machine.
>
>
>
> Are there any outstanding patches or workarounds I need to build lldb on
> Power8?
>
> This “https://github.com/PPC64/lldb” is the repository we are using to
> development (using “next” branch).
>
> Also there are “https://github.com/PPC64/clang” and “
> https://github.com/PPC64/llvm” as fixed references to avoid, for example,
> use lldb with the llvm from upstream repository in a different version.
>
> Using these versions it should build.
>
> Thanks,
>
> Leonardo.
>
>
>
>
>
> Thanks
>
> Sean
>
>
>
>
> On Thu, Nov 30, 2017 at 10:09 AM, Leonardo Bianconi <
> leonardo.bianconi at eldorado.org.br> wrote:
>
> But where is the flat set? Maybe I can debug and check what is going on.
>
>
>
> There is the possibility to be lldb usage, but it’s obtaining the
> disassembler as it is.
>
> When lldb tries to instantiate the disassembler, it checks many
> information in
>
> llvm/tools/lldb/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp:1014
> =
>
> “DisassemblerLLVMC::DisassemblerLLVMC(const ArchSpec &arch, const char
> *flavor_string)”,
>
> which I couldn’t find if it’s doing correct. Is there a place that
> explains the “flavor” and
>
> “features_str” variables used at DisassemblerLLVMC.cpp:1163
>
> (“newLLVMCDisassembler(triple_str, cpu, features_str.c_str(), flavor,
> *this)”)?
>
>
>
> Another question that I have is, how can I compare the data it gets with
> the real instructions?
>
> I found the file “PPCGenDisassemblerTables.inc”, where the table is
> declared, and where the it
>
> is decoded, so the current instruction bne cr7,0x2000092c (0x409e000c) is
> being processed by
>
> the case 30 in the PPCGenDisassemblerTables.inc file:
>
>       case 30:
>
>         tmp = fieldFromInstruction(insn, 21, 5);
>
>         if (decodeUImmOperand<5>(MI, tmp, Address, Decoder) ==
> MCDisassembler::Fail) { return MCDisassembler::Fail; }
>
>         tmp = fieldFromInstruction(insn, 16, 5);
>
>         if (DecodeCRBITRCRegisterClass(MI, tmp, Address, Decoder) ==
> MCDisassembler::Fail) { return MCDisassembler::Fail; }
>
>         tmp = fieldFromInstruction(insn, 2, 14);
>
>         MI.addOperand(MCOperand::createImm(tmp));
>
>         return S;
>
>
>
> Which is the correct reading for the BC instruction. What am I missing?
>
>
>
> Some additional information:
>
> MCInst opcode: 0x7cb
>
> Decode Index: 0x1e
>
>
>
> =================
>
>
>
> Test case:
>
>
>
> -          Build the file “lldb/packages/Python/lldbsuite/test/
> functionalities/stop-hook/main.cpp”
>
> -          Run LLDB with the binary just generated
>
> -          Add the breakpoint “b main.cpp:30”
>
> -          Send the command “n”, stepping over to next line.
>
> Result: The debugger will not stop and will execute the entire binary.
>
>
>
> Remembering I’m using a little endian Power8 machine.
>
>
>
>
>
> Thanks!
>
>
>
>
>
> *From:* Nemanja Ivanovic [mailto:nemanja.i.ibm at gmail.com]
> *Sent:* quinta-feira, 30 de novembro de 2017 07:54
> *To:* Sean Fertile <sd.fertile at gmail.com>
> *Cc:* Leonardo Bianconi <leonardo.bianconi at eldorado.org.br>;
> llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] PPC64 Disassembler
>
>
>
> The `isBranch` flag is already set on the branch instructions.
> Furthermore, we do use the `isBranch()` query in a few places in the PPC
> back end, so this does work. Perhaps there's something specific about the
> lldb usage? Is it somehow possible that the `isBranch()` query is called on
> the wrong instruction?
>
> Would you be able to provide a test case that reproduces the issue?
>
>
>
> On Thu, Nov 30, 2017 at 2:30 AM, Sean Fertile via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hello Leonardo,
>
> What is the opcode of the MCInstrDesc?
>
> Sean
>
>
> On Wed, Nov 29, 2017 at 1:48 PM, Leonardo Bianconi via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Hi all,
> >
> >
> >
> > I’m working on lldb to make it available to ppc64le, but the “step over”
> >
> > is not working for some cases.
> >
> >
> >
> > When debugging, I can see that the disassembler analyze some instructions
> >
> > forward, looking for a branch instruction
> >
> > (llvm/tools/lldb/source/Plugins/Disassembler/llvm/
> DisassemblerLLVMC.cpp:87
> >
> > – “const bool can_branch = mc_disasm_ptr->CanBranch(inst);”), while
> >
> > trying to set the next breakpoint.
> >
> >
> >
> > On this case, the instruction is the “bne     cr7,0x2000092c”, which is a
> > branch,
> >
> > but at llvm/lib/MC/MCInstrDesc.cpp:35 –
> >
> > “if (isBranch() || isCall() || isReturn() || isIndirectBranch())” it
> returns
> > false,
> >
> > making lldb do not set the correct breakpoint, so the execution does not
> > stop
> >
> > at next line, which should be the “step over” behavior.
> >
> >
> >
> > The variable “Flags” for the disassembled instruction does not have the
> > branch
> >
> > flag.
> >
> >
> >
> > I have tried to change the file “/lib/Target/PowerPC/PPCInstrInfo.td”,
> > adding
> >
> > “isBranch = 1” for the instruction "bc 4, $bi, $dst", but had not effect.
> >
> >
> >
> > Comparing with x86_64, building the same cpp file, the instruction
> >
> > “jne    0x4005eb” has the branch flag, which identifies it as a branch
> > instruction.
> >
> >
> >
> > Where is the definition that an instruction is a branch? Is it a bug?
> >
> >
> >
> > Thanks!
> >
> >
>
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
>
> _______________________________________________
> 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/20171222/fcca6dfd/attachment-0001.html>