[llvm-dev] PPC64 Disassembler
Leonardo Bianconi via llvm-dev
llvm-dev at lists.llvm.org
Fri Dec 1 03:14:33 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.
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<mailto: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<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<mailto:sd.fertile at gmail.com>>
Cc: Leonardo Bianconi <leonardo.bianconi at eldorado.org.br<mailto:leonardo.bianconi at eldorado.org.br>>; llvm-dev at lists.llvm.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/20171201/16e819e6/attachment.html>
More information about the llvm-dev
mailing list