Displaying 20 results from an estimated 10000 matches similar to: "RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value"
2017 Sep 06
2
RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value
It's worth remembering that there are two syntactically similar but semantically different kinds of "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
2017 Sep 05
7
RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value
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
2017 Sep 07
2
RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value
On Wed, Sep 6, 2017 at 5:01 PM, David Blaikie <dblaikie at gmail.com> wrote:
> On Wed, Sep 6, 2017 at 2:01 PM Reid Kleckner <rnk at google.com> wrote:
>
>> On Wed, Sep 6, 2017 at 10:01 AM, David Blaikie <dblaikie at gmail.com>
>> wrote:
>>
>>> I guess you described this already, but talking it through for
>>> myself/maybe others will
2017 Sep 07
2
RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value
On Thu, Sep 7, 2017 at 9:46 AM, David Blaikie <dblaikie at gmail.com> wrote:
> Feels to me like bugs rather than inconsistencies (I'd think of an
> inconsistency as "we do X over here intentionally and Y over here
> intentionally but they're in contradiction to one another")
>
The DBG_VALUE MachineInstr actually already has a way to indicate that the
computed
2017 Sep 06
4
RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value
On Wed, Sep 6, 2017 at 10:01 AM, David Blaikie <dblaikie at gmail.com> wrote:
> On Tue, Sep 5, 2017 at 1:00 PM Reid Kleckner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> LLVM SSA values obviously do not have an address that we can take and
>> they don’t live in registers, so neither the default memory location model
>> nor DW_OP_regN make sense
2017 Sep 11
2
Unify debug and optimized variable locations with llvm.dbg.addr [was: DW_OP_LLVM_memory]
On Fri, Sep 8, 2017 at 10:32 AM, Adrian Prantl <aprantl at apple.com> wrote:
> > On Sep 7, 2017, at 2:18 PM, Reid Kleckner <rnk at google.com> wrote:
> >
> > On Thu, Sep 7, 2017 at 11:11 AM, Robinson, Paul <paul.robinson at sony.com>
> wrote:
> >> Different intrinsics sounds like a good solution to me. J
> >>
> >> So what happens
2017 Sep 07
5
RFC: Unify debug and optimized variable locations with llvm.dbg.addr [was: DW_OP_LLVM_memory]
I chatted with Chandler in person and came up with what I think is a much
simpler design than my previous design in the thread titled "RFC: Introduce
DW_OP_LLVM_memory to describe variables in memory with dbg.value".
The crux of the problem in that thread is that we need a representation,
particularly in the middle-end, to describe a variables address, at a
particular program point.
2020 Sep 16
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> That makes sense, and I think for "direct" values in your definition it is true that all direct values are r-values.
> Why do we need DW_OP_LLVM_direct when we already have DW_OP_LLVM_stack_value? Can you give an example of something that is definitely not a stack value, but direct?
The difference in definition is the intention: DW_OP_LLVM_direct means "we'd like this
2017 Sep 07
3
Unify debug and optimized variable locations with llvm.dbg.addr [was: DW_OP_LLVM_memory]
On Thu, Sep 7, 2017 at 11:11 AM, Robinson, Paul <paul.robinson at sony.com>
wrote:
> Different intrinsics sounds like a good solution to me. J
>
>
>
> So what happens with the case where a variable is registerized but later
> we decide to spill it? Presumably we'd have a dbg.addr to point to the
> spill slot. In past compilers I've used, spill slots were
2020 Oct 07
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> I don't see how this is a meaningful distinction in LLVM IR. In LLVM IR we only have SSA values. An SSA value could be an alloca, or a gep into an alloca, or spilled onto the stack at the MIR level, in which case the dbg.value should get lowered into a memory location (if it isn't explicitly a DW_OP_stack_value).
I think the distinction is still important; even at the IR level, if we
2020 Sep 04
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> Yeah, because that decision can only be made much later in LLVM in AsmPrinter/DwarfExpression.cpp.
> In DWARF, DW_OP_reg(x) is a register l-value, all others can either be l-values or r-values depending on whether there is a DW_OP_stack_value/DW_OP_implicit* at the end.
Yes, it might not be clear but that's what I'm trying to say. Out of the non-empty DWARF locations, register and
2020 Sep 02
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> I'm not sure this will work as stated here. Indirectness is (mostly) orthogonal to DW_OP_stack_value. DW_OP_stack_value denotes that we reconstructed the value of the variable, but it doesn't exist in the program ("The DW_OP_stack_value operation specifies that the object does not exist in memory but its value is nonetheless known"), for example, a constant value. I think we
2020 Aug 25
3
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
Currently there is a series of patches undergoing review[0] that seek to enable the use of multiple IR/MIR values when describing a source variable's location. The current plan for the MIR is to add a new instruction, DBG_VALUE_LIST, that supports this functionality by having a variable number of operands. It may be better however to simply replace the existing DBG_VALUE behaviour entirely
2020 Sep 15
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> That sounds to me to be the same concept that I am calling r-value vs. l-value. Do you agree, or is there some subtlety that I am missing?
I've been assuming that the l-value vs r-value distinction is analogous to C++: an l-value can be written to by the debugger, an r-value cannot. A memory location and a register location are both l-values, while implicit locations (stack
2016 Jul 29
3
IR @llvm.dbg.value entries for variables when a phi node has been created
I have been investigating missing variables / incorrect variable values when debugging code compiled at -O1 (and above) and believe that I have tracked the issue down to the interaction of the generation of IR @llvm.dbg.value entries and phi nodes. I would welcome someone who is more familiar with the generation of debug information to help me determine if what I think is going wrong is correct
2010 Jul 17
2
[LLVMdev] llvm.dbg.declare
Hi folk,
In the Source Level Debugging document, llvm.dbg.declare takes two
paramters. "The first argument is the alloca for the variable, cast to a
{}*. The second argument is the llvm.dbg.variable containing the description
of the variable." The second parameter corresponds to DIVariable, what is
the corresponding LLVM class of the first parameter? I want to find which
2020 Sep 11
2
[Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands
> 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
2020 Apr 15
4
Seeking clarification and way forward on limited scope variables.
Hi Sourabh,
Thanks for raising this issue. To answer your question, (afaik) there isn’t anyone working on DW_AT_start_scope support in tree. We’re looking for a solution to this problem for Swift debugging, where it's important not to make a debug location for a variable available until its (guaranteed) initialization is complete.
If at all possible, I’d /much/ rather we use the existing
2010 Jul 19
0
[LLVMdev] llvm.dbg.declare
On Sat, Jul 17, 2010 at 12:00 AM, Neal N. Wang <neal.wang at gmail.com> wrote:
> Hi folk,
>
> In the Source Level Debugging document, llvm.dbg.declare takes two
> paramters. "The first argument is the alloca for the variable, cast to a
> {}*. The second argument is the llvm.dbg.variable containing the description
> of the variable." The second parameter
2016 Jul 31
0
IR @llvm.dbg.value entries for variables when a phi node has been created
+Adrian Prantl <aprantl at apple.com> who might have some ideas about the
representation choices/current/future behavior here
On Fri, Jul 29, 2016 at 12:27 PM Keith Walker via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I have been investigating missing variables / incorrect variable values
> when debugging code compiled at –O1 (and above) and believe that I have
>