search for: dbg_value_var

Displaying 4 results from an estimated 4 matches for "dbg_value_var".

2020 Jul 07
2
Defining the DIExpression operator DW_OP_LLVM_arg
Currently, two patches undergoing review wish to add a new operator for LLVM's DIExpression: D70642[0], and D82363[1]. Though both of these cases use the same name, the operators have different meanings: in the former, it has the form `DW_OP_LLVM_argN` where N is in [0-7], and represents the Nth argument of the containing intrinsic; its purpose is to enable the intrinsic @llvm.dbg.derefval,
2020 Jul 08
3
Defining the DIExpression operator DW_OP_LLVM_arg
...so, for the sake of not bloating the final DWARF we wouldn't want to actually push the args onto the stack first and then pick them, so we'd basically be treating the final DW_OP_pick operators as DW_OP_LLVM_arg either way. > By restricting their use to new intrinsics only (derefval and DBG_VALUE_VAR) we can avoid any confusion about whether argument 0 is implicitly pushed to the stack or not — in those new intrinsics, arguments always have to be referred to explicitly. Personally, I'm leaning more towards DW_OP_LLVM_argN, because of the space saving aspect. I think what you're saying...
2020 Jul 08
2
Defining the DIExpression operator DW_OP_LLVM_arg
...k first and then pick them, so we'd basically be treating the final DW_OP_pick operators as DW_OP_LLVM_arg either way. > > Agreed. I think everyone can agree that this operator is a useful addition. > > > > >> By restricting their use to new intrinsics only (derefval and DBG_VALUE_VAR) we can avoid any confusion about whether argument 0 is implicitly pushed to the stack or not — in those new intrinsics, arguments always have to be referred to explicitly. Personally, I'm leaning more towards DW_OP_LLVM_argN, because of the space saving aspect. > > > > I think what...
2020 Jul 08
2
Defining the DIExpression operator DW_OP_LLVM_arg
...ically be treating the final DW_OP_pick operators as DW_OP_LLVM_arg either way. > >> > >> Agreed. I think everyone can agree that this operator is a useful addition. > >> > >>> > >>>> By restricting their use to new intrinsics only (derefval and DBG_VALUE_VAR) we can avoid any confusion about whether argument 0 is implicitly pushed to the stack or not — in those new intrinsics, arguments always have to be referred to explicitly. Personally, I'm leaning more towards DW_OP_LLVM_argN, because of the space saving aspect. > >>> > >>&...