gdb-remote protocol questions

Subprojects LLDB
1

Hi,

I’ve been implementing a basic RSP protocol server for remotely debugging a MIPS simulator, and have been having some trouble getting certain lldb features to work there, in particular backtraces (bt) and instruction step over (ni). Does someone know what packets these commands rely on to work? I’ve attached some communication logs, and if it helps my code is at https://github.com/CQCumbers/nmulator/blob/master/src/debugger.h

Please forgive me if this isn’t the right place to ask - I know this isn’t directly part of lldb development but I’ve tried several other places and haven’t been able to find anyone familiar with the subject.

Also, just a user question, but is there a way to show register values in hex format without leading zeros?

Thanks,
Alexander

packets.txt (18.1 KB)

2

I suspect your problem may be related to lldb not knowing how to walk the stack on this target. Is mips-unknown-linux-gnu correct? What do you see if you turn on unwind logging, 'log enable lldb unwind'. You can also have lldb show you the unwind rules at the current pc value with 'image show-unwind -a $pc'. I don't know what unwinders we have defined for this target in lldb right now -- if you have eh_frame information in your binary, lldb should read & use that. Otherwise, if you have an assembly instruction profiler in lldb for mips, and start addresses for your functions, lldb should be able to inspect the instruction stream and figure out how to unwind out of the function correctly. As a last resort, it will fall back to architecture rules for how to backtrace out of a function (defined in the ABI plugin) but those are often incorrect in prologue/epilogues (start & end of a function).

(btw if you support no-ack mode, there's a lot less packet traffic between your stub and lldb - recommended.)

J

3

Hi,

Thanks for pointing me towards stack unwinding. I don’t have debug information much of the time, so I’m depending on the architecture rules for backtracing. A look at the mips ABI plugin shows it uses dwarf register numbers to get the register values it needs, and I wasn’t including them in my qRegisterInfo responses. After fixing this, step over and step out appear to work correctly, which is a great help.

However, backtraces only show 2 frames with the current pc and ra values, no matter where I am, so it seems there’s some problem getting stack frame info from the actual stack. I’ve attached an unwind log from running bt inside a function that should have a deeper backtrace. The afa value of 0xffffffffffffffff looks suspicious to me, but I don’t really understand where it comes from. The frame before 0x8002ee70 should, I think, be 0x80026a6c, as that’s the pc after stepping out twice.

Thanks,
Alexander

packets.txt (1.82 KB)

4

Hi Alexander,

I am pretty sure the AFA is a red herring and you needn't worry about
it. It is only used in some very specific circumstances, when a function
realigns the stack pointer (e.g. when you have a over-aligned local
variable), and only on x86 I believe. Everyone else gets a 0xfff...f
value, and that's fine.

pl

5

Hi Alexander, sorry for the delay in replying.

The attached unwind log shows that lldb is using the architectural default unwind plan for this target. You can see where this unwind plan in constructed at

ABISysV_mips::CreateDefaultUnwindPlan

it says to find the caller's pc value at *($r29),

  // Our Call Frame Address is the stack pointer value
  row->GetCFAValue().SetIsRegisterPlusOffset(dwarf_r29, 0);

The default unwind plan says to find the caller's pc value in $r31,

  // The previous PC is in the RA
  row->SetRegisterLocationToRegister(dwarf_pc, dwarf_r31, true);
  unwind_plan.AppendRow(row);

which is fine for frame 0, we can look at $r31, but as soon as we move off of frame 0, we have to find the saved $r31 value on the stack (frame 0 had to spill it to the stack, right).

Unfortunately we don't have the function bounds of frame 0, we only have the architectural default unwind plan. This default unwind plan cannot do the right thing except on frame 0.

On other architectures where a return address register is used, like arm, the default unwind plan assumes that the pc and saved frame pointer have been spilled to stack, and there is a convention that they're the first two things spilled to stack. So we see in ABISysV_arm::CreateDefaultUnwindPlan,

  row->SetRegisterLocationToAtCFAPlusOffset(fp_reg_num, ptr_size * -2, true);
  row->SetRegisterLocationToAtCFAPlusOffset(pc_reg_num, ptr_size * -1, true);

We also have a ABISysV_arm::CreateFunctionEntryUnwindPlan unwind plan that is guaranteed to be valid at the first instruction of a function; it says that the saved PC is in the return address register,

  // Our Call Frame Address is the stack pointer value
  row->GetCFAValue().SetIsRegisterPlusOffset(sp_reg_num, 0);

  // The previous PC is in the LR
  row->SetRegisterLocationToRegister(pc_reg_num, lr_reg_num, true);
  unwind_plan.AppendRow(row);

although I should warn that I'm 99% sure that "nexti" doesn't currently record the fact that it is potentially stepping into a function, so lldb doesn't know to use the FunctionEntryUnwindPlan. We prob should.

fwiw the 0xffffffffffffffff value is lldb's LLDB_INVALID_ADDRESS.

J