search for: dw_op_regx

...RegOriginal + (0x70 - 0x50) = RegOriginal + 0x20 = RegOriginal + DW_OP_not Since we know that RegOriginal >= 32, the opcode that gets generated is one that has a value >= 0x40, which is DW_OP_lit16. There is a very similar snippet in the addAddress() function. It uses the DW_OP_regx opcode to encode the register number: // ... if (Location.isReg()) { if (Reg < 32) { addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_reg0 + Reg); } else { addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_regx); addUInt(Block, 0, dwarf::DW_FORM_udata, Reg);...

..."expression" in DWARF. A DWARF expression computes a value; if the available value is a pointer, you add DW_OP_deref to express the pointed-to value. A DWARF location expression computes a location, and adds various operators to express locations that a (value) expression cannot, such as DW_OP_regx. You also have DW_OP_stack_value to say "just kidding, this location expression is a value expression." So, whether we want to start throwing around deref or stack_value or regx (implicit or explicit) really depends on whether we are going to be using value expressions or location expres...

...> 1. How can we specify which register should be DW_AT_frame_base? > > You don't need to, there is a DWARF location expression in the > DW_AT_frame_base attribute attached to the function: > > DW_AT_frame_base( regx 0x0000003c ) > > This means: > > DW_OP_regx(0x0000003c) > > Or that the frame base is in register 0x3c. Now qRegisterInfo packets you > send back to LLDB must include "DWARF" register numbers. Sometimes the > register numbers the compiler uses for EH frame (from the .eh_frame > section) differ from the register numbe...

Thank you, Clayton. This is very helpful. We use the LLDB specific GDB remote extensions, and our debugger server supports "qRegisterInfo" package. "reg 0x3c" is the frame pointer. In the example mentioned above, we have SP = FP - 40 for current call frame. And variable "a" is stored at address (FP + -24) from asm instruction [FP + -24] = R3;; Thus we can conclude

...CFA management. winedbg: Store for context variables only the offsets of each register (instead of the address of the register in dbg_context). dbghelp: In dwarf attribute parsing, ensure that we do have a block when parsing a block. dbghelp: In dwarf parsing, correctly handle the DW_OP_regx option. dbghelp: Rewrite SymGetModuleBase so that it relies on 64 bit version. dbghelp: When unwinding the stack, stop if the current address isn't in a known module. winedbg: Store the CONTEXT in each stack frame to enable register access in the non topmost frames. wine...

Debug info today handles two cases reasonably well: 1. At -O0, dbg.declare does a good job describing variables that live at some known stack offset 2. With optimizations, variables promoted to SSA can be described with dbg.value This leaves behind a large hole in our optimized debug info: variables that cannot be promoted, typically because they are address-taken. This is