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
> 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:
DW_OP_addr(0x1000)
stack[0] = 0x2001000 (type = load address)
DW_OP_stack_value
stack[0] = 0x2001000 (type = stack value)
Where as in a debugger that wasn't running we will have:
DW_OP_addr(0x1000)
stack[0] = 0x1000 (type = file address)
DW_OP_stack_value
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@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
