PPC64 Disassembler

Project Infrastructure LLVM Dev List Archives
1

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!

2

Hello Leonardo,

What is the opcode of the MCInstrDesc?

Sean

3

Hi Sean,

Yes, it is. It has the method "isBranch()", which checks the "Flags"
variable if the branch bit is set.

Leonardo Bianconi.

4

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?

5

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

6

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

7

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

8

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