[Dwarf-Discuss] implicit_value vs stack_value

Greg Clayton clayborg at gmail.com
Mon Jan 4 14:11:24 PST 2021

DW_OP_implicit_value, as you said, allows encoding a constant that can be larger than the stack value size, so it will always be needed for these kinds of constant values.

> On Jan 4, 2021, at 11:30 AM, Paul Robinson via Dwarf-Discuss <dwarf-discuss at lists.dwarfstd.org> wrote:
> Happy New Year, everybody!
> A colleague just had a question for me about DW_OP_implicit_value
> which led me to wonder why we have both that and DW_OP_stack_value.
> Looking at http://dwarfstd.org/ShowIssue.php?issue=071227.1 which
> introduced the latter, it says in part:
>  (This operator is similar to DW_OP_implicit_value, issue "070426.1".  The
>  latter only permits the description of values known to be literals at
>  compile-time; this proposal permits the description of values which
>  have known expressions at compile-time.  It is more general; since 
>  a sequence of DW_OP_constxx, DW_OP_value can replace every instance
>  of DW_OP_implicit_value, this proposal also includes the removal of
>  DW_OP_implicit value from the standard.)
> ...although I don't think "the removal of DW_OP_implicit_value" actually
> happened.
> I have come up with only two advantages that DW_OP_implicit_value would
> have, compared to DW_OP_stack_value:
> 1) it can express a value larger than one expression-stack element in
>   a single operation;
> 2) it's faintly possible that it's simpler for a producer to produce.
> But, DW_OP_stack_value would frequently result in a more compact 
> representation, for example:
>  DW_OP_implicit_value 4 0 0 0 0 => 6 bytes
>  DW_OP_lit0 DW_stack_value => 2 bytes

DW_OP_stack_value can be used after a complex expression to just say that "the value on the stack if the value of the expression result and we are done". 

DWARF, prior to version 5, required expression evaluation to just know what kind of value something was on the expression stack and "do the right thing". DWARF5 cleared this up with more clearly defined rules and DW_OP_stack_value was one of those things. DW_OP_addr has a value that is a virtual address in a file and the expression evaluation needs to do the right thing. If we wanted to make an expression that got the address of a global variable, you could use:

DW_OP_addr(0x1000) DW_OP_stack_value

If you have a running process, you would convert address 0x1000 to the address that this this .data was loaded in the process and push it on the stack, and then the DW_OP_stack_value would let you know that the result _is_ the value even though it started off as a file address and got converted to a load address. So in a running process with a .data segment whose file address was 0x1000 and is loaded at 0x2001000 we would have an expression stack like:

stack[0] = 0x2001000 (type = load address)

stack[0] = 0x2001000 (type = stack value)

Where as in a debugger that wasn't running we will have:

stack[0] = 0x1000 (type = file address)

stack[0] = 0x1000 (type = stack value)

So the DW_OP_stack_value allows expressions to clearly state that the expression result is on the stack and isn't a file or load address in case you end up using multiple different opcodes (DW_OP_addr, DW_OP_breg, DW_OP_reg, DW_OP_const, etc) that might muddy the waters was to what the resulting value is. 

> I don't see much value 😉 in actually deprecating or removing
> DW_OP_implicit_value, now that it's out in the world; is it worth
> adding a non-normative note that DW_OP_stack_value is actually more
> general?

They are two different opcodes. DW_OP_implicit_value makes constant values that do not need to fit into a 32 or 64 bit value and that doesn't push anything onto the stack, and DW_OP_stack_value allows you to change what the type of the top stack value is, no matter how it was created.

> Thanks,
> --paulr
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

More information about the Dwarf-Discuss mailing list