search for: dw_op_plus_uconst

...9 <2>< 2258> DW_TAG_member DW_AT_name __tib DW_AT_type <2228> DW_AT_decl_file 65 DW_AT_decl_line 10 DW_AT_data_member_location DW_OP_plus_uconst 0 <2>< 2274> DW_TAG_member DW_AT_name __gcstate DW_AT_type <156> DW_AT_decl_file 65 DW_AT_decl_line 11 DW_AT_data_member_location DW_OP_p...

...; 2258> DW_TAG_member > DW_AT_name __tib > DW_AT_type <2228> > DW_AT_decl_file 65 > DW_AT_decl_line 10 > DW_AT_data_member_location DW_OP_plus_uconst 0 > <2>< 2274> DW_TAG_member > DW_AT_name __gcstate > DW_AT_type <156> > DW_AT_decl_file 65 > DW_AT_decl_line 11 > DW_AT...

...; 2258> DW_TAG_member > DW_AT_name __tib > DW_AT_type <2228> > DW_AT_decl_file 65 > DW_AT_decl_line 10 > DW_AT_data_member_location DW_OP_plus_uconst 0 > <2>< 2274> DW_TAG_member > DW_AT_name __gcstate > DW_AT_type <156> > DW_AT_decl_file 65 > DW_AT_decl_line 11 > DW_AT...

...AG_member >> DW_AT_name __tib >> DW_AT_type <2228> >> DW_AT_decl_file 65 >> DW_AT_decl_line 10 >> DW_AT_data_member_location DW_OP_plus_uconst 0 >> <2>< 2274> DW_TAG_member >> DW_AT_name __gcstate >> DW_AT_type <156> >> DW_AT_decl_file 65 >> DW_AT_decl_line 11 >&g...

...ero (it does) we je to .LBB0_10 aka .Ltmp34. At which point we happily stomp on the value of 12(%esp) by spilling something *else* over it: .LBB0_10:                               # %if.end28 .Ltmp34: #DEBUG_VALUE: mp_register_ioapic:address <- $esi #DEBUG_VALUE: mp_register_ioapic:cfg <- [DW_OP_plus_uconst 8] [$ebp+0] .loc 2 0 1 is_stmt 0         # arch/x86/kernel/apic/io_apic_b.c:0:1 movl %ebx, 12(%esp)          # 4-byte Spill movl %edi, 20(%esp)          # 4-byte Spill Compare with the noretpoline.s version where those offsets from %esp are different: .LBB0_10:                               #...

...eceding expression is equal to an l-value. So for example: DBG_VALUE $rsp, !"x", !DIExpression(DW_OP_LLVM_direct) => DW_OP_reg7 RSP DBG_VALUE $rsp, !"x", !DIExpression(DW_OP_deref, DW_OP_LLVM_direct) => DW_OP_breg7 RSP+0 DBG_VALUE $rsp, !"x", !DIExpression(DW_OP_plus_uconst, 4, DW_OP_LLVM_direct) => DW_OP_breg7 RSP+4, DW_OP_stack_value Your point about the semantics of variable assignments in the debugger is useful, that clears up my misunderstandings. I believe that even with that in mind, LLVM_direct (or whatever name it takes) would be appropriate. If we recogn...

On Fri, 2018-02-09 at 10:36 +0000, David Woodhouse wrote: > > Did you get anywhere with the function attribute? Having isolated the > next boot failure to "it goes away if I compile io_apic.c without > retpoline", bisecting it per-function would help to further delay the > bit where I actually have to start *thinking*... It's mp_register_ioapic(), and only when

...AG_member >> DW_AT_name __tib >> DW_AT_type <2228> >> DW_AT_decl_file 65 >> DW_AT_decl_line 10 >> DW_AT_data_member_location DW_OP_plus_uconst 0 >> <2>< 2274> DW_TAG_member >> DW_AT_name __gcstate >> DW_AT_type <156> >> DW_AT_decl_file 65 >> DW_AT_decl_line 11 >&g...

...othetical "DIExpression optimizer" pass applied to the following code: // `int a` is live... int b = a + 5; int c = b - 5; If both b and c are optimized out and salvaged, then we end up with the following dbg.values: @llvm.dbg.value(i32 %a, !"b", !DIExpression(DW_OP_plus_uconst, 5, DW_OP_LLVM_direct)) @llvm.dbg.value(i32 %a, !"c", !DIExpression(DW_OP_plus_uconst, 5, DW_OP_constu, 5, DW_OP_minus, DW_OP_LLVM_direct)) ; DIExpressions optimized... @llvm.dbg.value(i32 %a, !"b", !DIExpression(DW_OP_plus_uconst, 5, DW_OP_LLVM_direct)) @llvm.db...

...Expression()), !dbg !41 %15 = getelementptr inbounds i32, i32* %11, i64 %14, !dbg !48 %16 = trunc i64 %14 to i32, !dbg !49 store i32 %16, i32* %15, align 4, !dbg !49, !tbaa !33 %17 = add nuw nsw i64 %14, 1, !dbg !50 call void @llvm.dbg.value(metadata i32 undef, metadata !26, metadata ! DIExpression(DW_OP_plus_uconst, 1, DW_OP_stack_value)), !dbg !41 %18 = load i32, i32* %8, align 4, !dbg !51, !tbaa !52 %19 = sext i32 %18 to i64, !dbg !42 %20 = icmp slt i64 %17, %19, !dbg !42 br i1 %20, label %13, label %12, !dbg !44, !llvm.loop !54 } --Snip--- Question is why the load IR and sext IR (obj.a) is not getting ho...

...t; DW_AT_name __tib >>> DW_AT_type <2228> >>> DW_AT_decl_file 65 >>> DW_AT_decl_line 10 >>> DW_AT_data_member_location DW_OP_plus_uconst 0 >>> <2>< 2274> DW_TAG_member >>> DW_AT_name __gcstate >>> DW_AT_type <156> >>> DW_AT_decl_file 65 >>> DW_AT_decl_line...

...ecause "directness" is already made explicit by the choice of intrinsic. Every dbg.value would implicitly be LLVM_direct unless it has another implicit location specifier (such as stack_value or implicit_ptr). This would mean that we could have a debug value: dbg.value(%a, "a", (DW_OP_plus_uconst, 5)), with no stack_value necessary, as opposed to the current case where every dbg.value with a complex expression has stack_value (I believe). As discussed, one of the key distinctions that DW_OP_LLVM_direct is used for is distinguishing between memory and register locations; this is exactly the...

> Can you elaborate what "direct" means? I'm having trouble understanding what the opposite (a non-exact value) would be. Apologies, "exact" was a misleading/incorrect term. By direct, I mean that the expression computes the value of the variable, as opposed to its memory address, or the value that it points to. Within LLVM, where we don't have DW_OP_reg/DW_OP_breg

.... At which point we happily stomp on > the value of 12(%esp) by spilling something *else* over it: > > .LBB0_10: # %if.end28 > .Ltmp34: > #DEBUG_VALUE: mp_register_ioapic:address <- $esi > #DEBUG_VALUE: mp_register_ioapic:cfg <- [DW_OP_plus_uconst 8] > [$ebp+0] > .loc 2 0 1 is_stmt 0 # arch/x86/kernel/apic/io_apic_ > b.c:0:1 > movl %ebx, 12(%esp) # 4-byte Spill > movl %edi, 20(%esp) # 4-byte Spill > > Compare with the noretpoline.s version where those offsets fro...

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

...rpose however, I instead propose that we treat this as a special (albeit common) case: we can use `DW_OP_LLVM_arg 0, DW_OP_stack_value` with a single register operand. We already reduce the DIExpression to specialized DWARF operators at the point of DWARF emission, for example: `<Register N>, DW_OP_plus_uconst 5` becomes `DW_OP_bregN RSP+5`. If in any case where a stack value expression consists of only a single register it is valid to convert it to a register location, then this should be a valid transformation; I can't think of any cases where it wouldn't be, since if we get a variable's va...

...n(var: !25, expr: !DIExpression()) !29 = distinct !DIGlobalVariable(scope: !20, name: "i", file: !3, type: !28) !30 = !DIGlobalVariableExpression(var: !29, expr: !DIExpression()) !31 = distinct !DIGlobalVariable(scope: !20, name: "j", file: !3, type: !28) !32 = !DIExpression(DW_OP_plus_uconst, 4) !33 = !DIGlobalVariableExpression(var: !31, expr: !32) The DWARF generated for this is as follows. DW_TAG_common_block: DW_AT_name: alpha DW_AT_location: @alpha_+0 DW_TAG_variable: DW_AT_name: common alpha DW_AT_type: array of 8 bytes DW_AT_location: @alpha_+0 DW_TAG_variable: DW...

> I can see how that could potentially be useful. I'm not sure how often we could practically make use of a situation like this, but I understand your motivation. Indeed, I don't expect us to cancel out DWARF expressions like that very often. Although that edge case is likely to be very rare, the _direct operator itself will appear very frequently, as it would be used for every

...cation(line: 0, scope: <0x111dc650>) call void @llvm.dbg.value(metadata i8* undef, metadata <0x111daf20>, metadata !DIExpression()), !dbg !DILocation(line: 0, scope: <0x111d4030>) call void @llvm.dbg.value(metadata i8* undef, metadata <0x111daf20>, metadata !DIExpression(DW_OP_plus_uconst, 3, DW_OP_stack_value)), !dbg !DILocation(line: 0, scope: <0x111d4030>) store i8 %i.06, i8* %lsr.iv, align 1, !dbg !DILocation(line: 5, column: 8, scope: <0x111ddc90>), !tbaa <0x111dd288> %inc = add nuw nsw i8 %i.06, 1, !dbg !DILocation(line: 3, column: 38, scope: <0x111dd5...

Hi Vedant, thanks for the detailed response, On Tue, Feb 25, 2020 at 7:23 AM Vedant Kumar <vedant_kumar at apple.com> wrote: > > Finally, being forced to always specify both the machine location and > > the program location at the same time (in a single DBG_VALUE) > > introduces un-necessary burdens. In MachineSink, when we sink between > > blocks an instruction that