search for: dw_op_breg0

...tion.getReg(), false); DIEBlock *Block = new (DIEValueAllocator) DIEBlock(); if (Location.isReg()) { if (Reg < 32) addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_reg0 + Reg); else { Reg = Reg - dwarf::DW_OP_reg0; addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_breg0 + Reg); addUInt(Block, 0, dwarf::DW_FORM_udata, Reg); } } else { if (Reg < 32) addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_breg0 + Reg); else { addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_bregx); addUInt(Block, 0, dwarf::DW_FORM_udata, Reg)...

Hi Devs, debug info emitted by llvm does not contain DW_AT_Location for Formal parameter if it is an aggregate like below case 1) aggregate contain more than 4 homogeneous and size more than 128 bits i.e. typedef struct{ int a,b,c,d,e; }mystruct; void foo(mystruct ms){ } 2) aggregate contain hetrogeneous type and size more than 128 bits. i.e. typedef struct{ int a,b; float c,d,e; }mystruct; void

...y determine whether or not a value is indirect; this brings us closer to the final DWARF representation. One potential downside is that using DW_OP_stack_value for a simple single-register DBG_VALUE (as in the example above) would currently lose information, as it would output the DWARF expression `DW_OP_breg0 RSP+0, DW_OP_stack_value` instead of the current output `DW_OP_reg0 RSP`. The former is larger and gives less information, as both expressions evaluate to the same value but only the latter gives a location for the variable that can be modified by a debugger. This can be fixed with some pattern mat...

...23, metadata !DIExpression(DW_OP_plus_uconst, 4, DW_OP_constu, 4, DW_OP_minus, DW_OP_stack_value)), !dbg !25 %add = shl i32 %call, 1, !dbg !26 ret i32 %add, !dbg !27 ; Final DWARF location for "a": DW_AT_location (0x00000000: [0x0000000000000029, 0x000000000000002b): DW_OP_breg0 RAX+4, DW_OP_constu 0xffffffff, DW_OP_and, DW_OP_lit4, DW_OP_minus, DW_OP_stack_value) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200916/1d35bbd8/attachment-0001.html>

Hi Adrian & Stephen, One thought here: But — not all memory locations are l-values. If we have a DWARF location list for variable "x" which points to a memory address for the first n instructions and the switches to a constant for the remainder of the scope, the memory address is not guaranteed to be an l-value, because writing the the memory address cannot affect the later part of

...y determine whether or not a value is indirect; this brings us closer to the final DWARF representation. One potential downside is that using DW_OP_stack_value for a simple single-register DBG_VALUE (as in the example above) would currently lose information, as it would output the DWARF expression `DW_OP_breg0 RSP+0, DW_OP_stack_value` instead of the current output `DW_OP_reg0 RSP`. The former is larger and gives less information, as both expressions evaluate to the same value but only the latter gives a location for the variable that can be modified by a debugger. This can be fixed with some pattern mat...