Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-24 Thread Bishop, John E via Dwarf-Discuss
> (1) What if the user chose the first of these options and the program
> changed the variable multiple times between lines 112 and 120?

That's a user error (or misunderstanding), just as in the case where the code 
was far simpler:

 Line  Source
  10A = 10
  11A = 11
  12B = A

...and the current PC/line was 11 (i.e. the program is about to execute line 
11), and the user issued the command:

  debugger-prompt> set A = 30

The debugger would obediently set A to 30.  But now a continue command from the 
user would execute line 11 and A would be set to 11.

> Should the debugger suppress the program's changes to ensure that the variable
> stays at the given value until line 120?

No!

> (2) Why does the user need to choose a location at all, instead of just
> using the location that matches the current PC?

1. As Ron pointed out, the current PC may correspond to more than one location.
2. The user is setting the variable value in order that a future use of the 
variable by the code will do what the user wants. This means that the user is 
focused on a future _use_ of the variable, not on the current value of the 
variable.
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-24 Thread Andreas Arnez via Dwarf-Discuss
On Fri, Jan 24 2020, Bishop, John E via Dwarf-Discuss wrote:

> With split lifetimes, the debugger can ask the user which of the
> lifetimes the user wants to set.
>
> debugger-prompt> set A = 3
> Variable 'A' has more than one location.  Choose which to set:
> 1.The location used in lines 112 and 120
> 2.The location used in line 111
> 3.All locations
> 4.None (no change)
> debugger-sub-menu-prompt> 

Can you clarify:

(1) What if the user chose the first of these options and the program
changed the variable multiple times between lines 112 and 120?  Should
the debugger suppress the program's changes to ensure that the variable
stays at the given value until line 120?

(2) Why does the user need to choose a location at all, instead of just
using the location that matches the current PC?

--
Andreas

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-24 Thread Frank Ch. Eigler via Dwarf-Discuss
Hi -

> With split lifetimes, the debugger can ask the user which of the
> lifetimes the user wants to set.  [...]  ...based on looking at the
> 'assign' location list.

Yup, those are reasonable user-interface ideas.  (I'm not sure we'd
require a whole separate location list, versus tagging the existing
one somehow; we'll see.)

- FChE

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-24 Thread Bishop, John E via Dwarf-Discuss
With split lifetimes, the debugger can ask the user which of the lifetimes the 
user wants to set. 

debugger-prompt> set A = 3
Variable 'A' has more than one location.  Choose which to set:
1.  The location used in lines 112 and 120
2.  The location used in line 111
3.  All locations
4.  None (no change)
debugger-sub-menu-prompt> 

A less sophisticated debugger might just do this:

   debugger-prompt> set A = 3
Variable 'A' has no unique location to set.

...based on looking at the 'assign' location list.

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-21 Thread Michael Eager via Dwarf-Discuss

On 1/21/20 3:17 PM, Greg Clayton via Dwarf-Discuss wrote:




On Jan 21, 2020, at 2:58 PM, Frank Ch. Eigler via Dwarf-Discuss 
 wrote:

Hi -


While dwarfdump has 'check the DWARF' options available the
location list overlap test is not done at all. The -kl option suggests
it does loclist checking, but its checking is rather superficial.


Note that one should not present these overlaps as -errors- (because
they may be accurate), but rather as complications for lvalue usage.



Indeed. Warnings might be nice if the locations expressions are the same _and_ 
the types are different.

It would be very hard to figure out in a language agnostic way if two types are not the same 
("int" and a typedef to a "int" for example for C based languages).


A checker can walk down the type tree to find if the two types have the
same base types.

Common subexpression elimination could reuse the computed value even if
the source types were different.  (In C, typedef is an alias for a type,
not a different type.  C++ is marginally more restrictive.)

A debugger could alert the user that another variable also occupies the
same location and has been modified.  That might reduce the surprise
factor.  But this depends on neither of the complication 3 cases being
true, and there may be no way to confirm this.  This might give the user
an even stronger false impression that the new value is being used, when
it isn't.

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-21 Thread Greg Clayton via Dwarf-Discuss



> On Jan 21, 2020, at 2:58 PM, Frank Ch. Eigler via Dwarf-Discuss 
>  wrote:
> 
> Hi -
> 
>> While dwarfdump has 'check the DWARF' options available the
>> location list overlap test is not done at all. The -kl option suggests
>> it does loclist checking, but its checking is rather superficial.
> 
> Note that one should not present these overlaps as -errors- (because
> they may be accurate), but rather as complications for lvalue usage.
> 

Indeed. Warnings might be nice if the locations expressions are the same _and_ 
the types are different.

It would be very hard to figure out in a language agnostic way if two types are 
not the same ("int" and a typedef to a "int" for example for C based 
languages). 

Maybe if we have two different DWARF types entirely, like one 
DW_TAG_structure_type and one DW_TAG_enumeration. We would also need to omit 
any values that are constants values since two different types could both have 
the same location expression in that case. There are many complexities involved.


> - FChE
> 
> ___
> 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


Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-21 Thread Frank Ch. Eigler via Dwarf-Discuss
Hi -

> While dwarfdump has 'check the DWARF' options available the
> location list overlap test is not done at all. The -kl option suggests
> it does loclist checking, but its checking is rather superficial.

Note that one should not present these overlaps as -errors- (because
they may be accurate), but rather as complications for lvalue usage.

- FChE

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-21 Thread David Anderson via Dwarf-Discuss




On 1/21/20 11:18 AM, Greg Clayton via Dwarf-Discuss wrote:

[...]
Presumably, a debugger could check that location lists do not
overlap.


This could nevertheless be a valid heuristic to detect the case.


the "llvm-dwarfdump" binary in llvm.org  has a
"--verify" option that looks for issues in DWARF and reports errors.
Not sure if there are any other tools out there that do this, but this
would be a great check to add to any DWARF verifier.






While dwarfdump has 'check the DWARF' options available the
location list overlap test is not done at all. The -kl option suggests
it does loclist checking, but
its checking is rather superficial.


 Interesting thing to check, I'll see if I can
 do something.

 David Anderson

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-21 Thread Greg Clayton via Dwarf-Discuss


> On Jan 20, 2020, at 6:21 PM, Frank Ch. Eigler via Dwarf-Discuss 
>  wrote:
> 
> Hi -
> 
>>> - ... and undoubtedly other complications exist!
>> 
>> Interesting question.
> 
> Thanks!
> 
> We have been thinking in similar directions generally as y'all.
> 
> 
>> Complication 2: The compiler reuses variable locations at the same PC. This
>> seems to be a compiler bug.  
> 
> (Actually, this could be a valid optimization, e.g.:
> 
>   int a = expression;
>   int b = expression;
>> 
>   /* use/modify a */
>   /* use/modify b */
> 
> at that point, if $expression is a pure function, a compiler
> could evaluate it once and reuse the value.  It could do this
> by temporarily storing both a and b in the same register, and
> only separating the variables afterwards.
> 
>> [...]
>> Presumably, a debugger could check that location lists do not
>> overlap.
> 
> This could nevertheless be a valid heuristic to detect the case.

the "llvm-dwarfdump" binary in llvm.org  has a "--verify" 
option that looks for issues in DWARF and reports errors. Not sure if there are 
any other tools out there that do this, but this would be a great check to add 
to any DWARF verifier.

> 
> 
>> Complication 3a: That the value of a variable has been fetched for a
>> computation before the debugger modifies it.  This is more complicated. The
>> live range of the variable is accurate, but its value has been used before
>> the current PC.  DWARF does not include descriptions of data flow or
>> indicate where variables are fetched, so there is no information that a
>> debugger can use to assure that a modified value is actually used.
> 
> Yeah, and in the absence of dataflow metadata, tools like dyninst must
> try to reverse-engineer the dataflow in order to perform binary
> rewriting.  Is this something way out of forseeable dwarf scope?
> 
> 
>> There are a lot of issues with a debugger modifying a program while it is
>> running.  A debugger can make essentially unbounded changes to the program
>> state.  Some of these may work as expected, some may not, and it is unclear
>> how a debugger would be able to know the difference.
> 
> This is the key question: how can a tool know what is safe.  While the
> trivial case of assuming every write is unsafe is not helpful :-), it
> could be okay to have fairly conservative heuristics, known-partial
> information, and rely on only clear signals to enable write
> operations.

As soon as optimization are in, the live ranges for many variables is quite 
sparse from my experience with most compilers. LLDB can detect when we are 
debugging optimized code. This is currently done by looking for the 
DW_AT_APPLE_optimized attribute on the DW_TAG_compile_unit, so this isn't 
available everywhere. But in general, if we know a program isn't optimized, 
then the variable locations are often live for much longer. But there is no 
guarantee that we can detect when things are optimized. 
> 
> 
> Anyway, it sounds like the next step is on us to analyze & prototype
> in a compiler (gcc?).  I'd also appreciate authors of other dwarf
> consumer and producer tools to mention whether they have considered
> this area, so as to collect a census.

I enjoy data mining DWARF for the information it contains, so the 
"llvm-dwarfdump --verify" is the main area I could see adding support for 
detecting when/if a compiler emits overlapping locations for variables. Let us 
know what you find out and what you end up doing. Very interesting to think 
about.
> 
> 
> - FChE
> 
> ___
> 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


Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-21 Thread Adrian Prantl via Dwarf-Discuss



> On Jan 20, 2020, at 2:20 PM, Frank Ch. Eigler via Dwarf-Discuss 
>  wrote:
> 
> Hi -
> 
> I have a question about variable location lists, but not their
> encoding, the use they are suitable for.  The basic debugging scenario
> is just reading variable values, for which this is fine, especially
> when high-quality compilers emit exquisitely detailed data for their
> optimized code.
> 
> But what about writes - as though one could edit the program to insert
> an assignment, and resume?  A whole slew of complications come up:
> 
> - trying to modify a variable permanently, but the compiler only
>  emitted -some- of its locations
> 
> - trying to modify a variable (and only one), but the compiler put two
>  variables into the same location at that PC
> 
> - expressions using that value as input might have already started
>  to be computed, so it may be too late to change it at the PC
>  in question
> 
> - ... and undoubtedly other complications exist!
> 
> A debugger cannot currently be told that any particular variable
> location expression is safe to use as an lvalue, something roughly
> "exclusive, exhaustive, -O0-equivalent".  I believe most debuggers
> don't even handle the multiple-locations case for writes at all.  I
> don't know why - assume complications are rare?  or we have kind of
> papered over the problem?
> 
> As a DWARF standard level matter, descriptive rather than prescriptive
> as it is, what might be the minimum extension required to communicate
> lvalue-safety to a debugger?  A DW_OP_lvalue_safe assertive wrapper
> around a real expression?


My reading of the Location Description was that only Single Simple Memory and 
Register Location Descriptions (2.6.1.1.2, 2.6.1.1.3) are safe to use as 
L-values in the debugger. In practice, even that may be difficult, since even 
without optimizations a too-clever register allocator or instruction selector 
may insert a copy of a register or may re-use a previously loaded copy of a 
memory location instead of loading it again for each use. Something like a 
DW_OP_describes_all_locations flag would be needed to communicate what the 
compiler did to the debugger.

>From my experience with LLVM, it might take some work to implement this 
>correctly, since compilers typically only track one value for debug info 
>purposes and don't yet have the infrastructure to keep track of alternative 
>locations.

-- adrian
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-20 Thread Michael Eager via Dwarf-Discuss

On 1/20/20 6:21 PM, Frank Ch. Eigler via Dwarf-Discuss wrote:

Complication 2: The compiler reuses variable locations at the same PC. This
seems to be a compiler bug.


(Actually, this could be a valid optimization, e.g.:

int a = expression;
int b = expression;
   >
/* use/modify a */
/* use/modify b */

at that point, if $expression is a pure function, a compiler
could evaluate it once and reuse the value.  It could do this
by temporarily storing both a and b in the same register, and
only separating the variables afterwards.


Yes, where b is a copy of a, they can occupy the same location.  That 
does raise the question about what happens when the user instructs the 
debugger to change b, expecting that a will not be affected.



Complication 3a: That the value of a variable has been fetched for a
computation before the debugger modifies it.  This is more complicated. The
live range of the variable is accurate, but its value has been used before
the current PC.  DWARF does not include descriptions of data flow or
indicate where variables are fetched, so there is no information that a
debugger can use to assure that a modified value is actually used.


Yeah, and in the absence of dataflow metadata, tools like dyninst must
try to reverse-engineer the dataflow in order to perform binary
rewriting.  Is this something way out of forseeable dwarf scope?


I think that describing the data flow would be large.  Essentially, copy 
most of the IR data into DWARF.  If you have ideas about how to 
represent a compressed data flow graph, let us know.  There might only 
be a need for a limited subset.



There are a lot of issues with a debugger modifying a program while it is
running.  A debugger can make essentially unbounded changes to the program
state.  Some of these may work as expected, some may not, and it is unclear
how a debugger would be able to know the difference.


This is the key question: how can a tool know what is safe.  While the
trivial case of assuming every write is unsafe is not helpful :-), it
could be okay to have fairly conservative heuristics, known-partial
information, and rely on only clear signals to enable write
operations.


I can't think of any heuristic that would work, unless the debugger does 
an analysis of the generated code to find where variables are actively 
being used.  It also seems most likely that a user might want to modify 
variable exactly when they are being used, not where they are quiescent.



Anyway, it sounds like the next step is on us to analyze & prototype
in a compiler (gcc?).  I'd also appreciate authors of other dwarf
consumer and producer tools to mention whether they have considered
this area, so as to collect a census.



--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-20 Thread Frank Ch. Eigler via Dwarf-Discuss
Hi -

> > - ... and undoubtedly other complications exist!
> 
> Interesting question.

Thanks!

We have been thinking in similar directions generally as y'all.


> Complication 2: The compiler reuses variable locations at the same PC. This
> seems to be a compiler bug.  

(Actually, this could be a valid optimization, e.g.:

   int a = expression;
   int b = expression;
  >
   /* use/modify a */
   /* use/modify b */

at that point, if $expression is a pure function, a compiler
could evaluate it once and reuse the value.  It could do this
by temporarily storing both a and b in the same register, and
only separating the variables afterwards.

> [...]
> Presumably, a debugger could check that location lists do not
> overlap.

This could nevertheless be a valid heuristic to detect the case.


> Complication 3a: That the value of a variable has been fetched for a
> computation before the debugger modifies it.  This is more complicated. The
> live range of the variable is accurate, but its value has been used before
> the current PC.  DWARF does not include descriptions of data flow or
> indicate where variables are fetched, so there is no information that a
> debugger can use to assure that a modified value is actually used.

Yeah, and in the absence of dataflow metadata, tools like dyninst must
try to reverse-engineer the dataflow in order to perform binary
rewriting.  Is this something way out of forseeable dwarf scope?


> There are a lot of issues with a debugger modifying a program while it is
> running.  A debugger can make essentially unbounded changes to the program
> state.  Some of these may work as expected, some may not, and it is unclear
> how a debugger would be able to know the difference.

This is the key question: how can a tool know what is safe.  While the
trivial case of assuming every write is unsafe is not helpful :-), it
could be okay to have fairly conservative heuristics, known-partial
information, and rely on only clear signals to enable write
operations.


Anyway, it sounds like the next step is on us to analyze & prototype
in a compiler (gcc?).  I'd also appreciate authors of other dwarf
consumer and producer tools to mention whether they have considered
this area, so as to collect a census.


- FChE

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-20 Thread Michael Eager via Dwarf-Discuss

On 1/20/20 2:20 PM, Frank Ch. Eigler via Dwarf-Discuss wrote:

Hi -

I have a question about variable location lists, but not their
encoding, the use they are suitable for.  The basic debugging scenario
is just reading variable values, for which this is fine, especially
when high-quality compilers emit exquisitely detailed data for their
optimized code.

But what about writes - as though one could edit the program to insert
an assignment, and resume?  A whole slew of complications come up:

- trying to modify a variable permanently, but the compiler only
   emitted -some- of its locations

- trying to modify a variable (and only one), but the compiler put two
   variables into the same location at that PC

- expressions using that value as input might have already started
   to be computed, so it may be too late to change it at the PC
   in question

- ... and undoubtedly other complications exist!


Interesting question.

Complication 1: That the compiler only emitted partial descriptions for 
the variable:  this seems to be a quality of implementation issue. 
There is nothing that a debugger can do if the compiler generates 
incomplete or misleading descriptions.  There is also no way that a 
debugger can ascertain that the compiler has generated a complete or 
accurate description.  Remedy: Fix the compiler.


Complication 2: The compiler reuses variable locations at the same PC. 
This seems to be a compiler bug.  While a location (e.g., a register) 
can be the location for multiple variables, the live ranges for these 
variables should not overlap.  The location lists for all variables 
should be disjoint.  Presumably, a debugger could check that location 
lists do not overlap.


For complication 3, an example might be
load  r1, =1
add   r1, var
PC ==>  store r1, var
There might be arbitrary additional instructions for multiple source 
statements interspersed.


This has has two variants:

Complication 3a: That the value of a variable has been fetched for a 
computation before the debugger modifies it.  This is more complicated. 
The live range of the variable is accurate, but its value has been used 
before the current PC.  DWARF does not include descriptions of data flow 
or indicate where variables are fetched, so there is no information that 
a debugger can use to assure that a modified value is actually used.


Complication 3b: That a variable's value may be modified after the 
debugger changes it at PC.  This is essentially a race condition.  Both 
the program and the debugger are updating the variable.  Last one wins.


> A debugger cannot currently be told that any particular variable
> location expression is safe to use as an lvalue, something roughly
> "exclusive, exhaustive, -O0-equivalent".  I believe most debuggers
> don't even handle the multiple-locations case for writes at all.  I
> don't know why - assume complications are rare?  or we have kind of
> papered over the problem?

There are a lot of issues with a debugger modifying a program while it 
is running.  A debugger can make essentially unbounded changes to the 
program state.  Some of these may work as expected, some may not, and it 
is unclear how a debugger would be able to know the difference.


There might be fewer problems modifying variables which are marked 
volatile.  But var in the example above could be volatile and the same 
issues would occur.


Are these complications rare?  Unclear.  I think that the great majority 
of debugger use is in displaying the value of variables, not in 
modifying them.


Have we papered over the problem?  Probably.  Debugging optimized code 
is difficult, even without trying to change the program state.


> As a DWARF standard level matter, descriptive rather than prescriptive
> as it is, what might be the minimum extension required to communicate
> lvalue-safety to a debugger?  A DW_OP_lvalue_safe assertive wrapper
> around a real expression?

Conceivably, location lists could be extended to include a flag to say 
that a variable is quiescent for a particular range of PC values and 
that a modification at that time would be persistent.  (A clear 
definition of quiescent would be needed.)


As Cary notes, a default or bounded location description might be used, 
but I don't believe that either implies that a variable is quiescent (or 
not) over the specified range.


--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-20 Thread Cary Coutant via Dwarf-Discuss
> A debugger cannot currently be told that any particular variable
> location expression is safe to use as an lvalue, something roughly
> "exclusive, exhaustive, -O0-equivalent".  I believe most debuggers
> don't even handle the multiple-locations case for writes at all.  I
> don't know why - assume complications are rare?  or we have kind of
> papered over the problem?
>
> As a DWARF standard level matter, descriptive rather than prescriptive
> as it is, what might be the minimum extension required to communicate
> lvalue-safety to a debugger?  A DW_OP_lvalue_safe assertive wrapper
> around a real expression?

In DWARF 5, we added the concepts of bounded and default location
descriptions. I think it would generally be safe to modify a value
under the following conditions:

(a) The variable's location is covered by a single location
description, or by a location list with a default location description
but where no bounded location description matches the current pc.

(b) Such location description is a simple memory or register location.

(c) You're stopped at a suggested breakpoint location.

I'm sure there are circumstances where you could still get into
trouble (e.g., your third example), but I think it would be unusual,
and there we'd probably be talking about a quality of implementation
issue. The courteous thing for a compiler to do would be to at least
try to make this ok at suggested breakpoint locations, though I
wouldn't expect a compiler at -O2 to deliberately avoid an
optimization solely for the sake of being able to modify a variable
while stopped at a breakpoint.

In your third example, once the compiler has loaded a copy of the
variable into a register to use in a computation, it could (should?)
create a bounded location description, thus marking it unsafe under
the rules above. So, rather than mark lvalue-safe regions, a compiler
could instead use a bounded location descriptions to mark a region
unsafe that wouldn't already be deemed unsafe.

-cary
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


[Dwarf-Discuss] variable locations - safe use as lvalues

2020-01-20 Thread Frank Ch. Eigler via Dwarf-Discuss
Hi -

I have a question about variable location lists, but not their
encoding, the use they are suitable for.  The basic debugging scenario
is just reading variable values, for which this is fine, especially
when high-quality compilers emit exquisitely detailed data for their
optimized code.

But what about writes - as though one could edit the program to insert
an assignment, and resume?  A whole slew of complications come up:

- trying to modify a variable permanently, but the compiler only
  emitted -some- of its locations

- trying to modify a variable (and only one), but the compiler put two
  variables into the same location at that PC

- expressions using that value as input might have already started
  to be computed, so it may be too late to change it at the PC
  in question

- ... and undoubtedly other complications exist!

A debugger cannot currently be told that any particular variable
location expression is safe to use as an lvalue, something roughly
"exclusive, exhaustive, -O0-equivalent".  I believe most debuggers
don't even handle the multiple-locations case for writes at all.  I
don't know why - assume complications are rare?  or we have kind of
papered over the problem?

As a DWARF standard level matter, descriptive rather than prescriptive
as it is, what might be the minimum extension required to communicate
lvalue-safety to a debugger?  A DW_OP_lvalue_safe assertive wrapper
around a real expression?


- FChE

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org