[llvm-dev] PPC64 Disassembler

Thu Nov 30 12:12:49 PST 2017

> 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.

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.

Are there any outstanding patches or workarounds I need to build lldb on
Power8?

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171130/17b65436/attachment.html>