From aoliva@redhat.com  Fri Mar 10 02:17:12 2017
From: aoliva@redhat.com (Alexandre Oliva)
Date: Thu, 09 Mar 2017 23:17:12 -0300
Subject: [Dwarf-Discuss] implementing SFN,
	support for multiple views per PC
In-Reply-To: <58AF499A.3060405@eagercon.com> (Michael Eager's message of "Thu, 
	23 Feb 2017 12:44:10 -0800")
References: <orfup8zwow.fsf@livre.home> <orpoi865kg.fsf@lxoliva.fsfla.org>
	<58AF499A.3060405@eagercon.com>
Message-ID: <orwpbxzxhz.fsf@lxoliva.fsfla.org>

On Feb 23, 2017, Michael Eager <eager at eagercon.com> wrote:

> Please submit comments/proposals online at http://dwarfstd.org/Comment.php.

> It greatly helps to specify the sections and pages that you propose
> changing, as well as the text changed, added, or removed.

Thanks, will do.

I guess I will need some more discussion here, before having a concrete
proposal, though, because of some changes prompted by changes in loclist
in DWARF5.  E.g., instead of what I had suggested, namely a separate
attribute:

>> A DIE with a DW_AT_location list may also have a DW_AT_locviews
>> attribute referencing a viewlist table.

and a separate list with matching entries for each loclist bounded
location description entry:

>> For each range in the location list (not its terminator), the viewlist
>> should contain a corresponding pair of entries, one corresponding to the
>> views that start and end the range.  Each view is encoded as a separate
>> uleb128 quantity.

we could have:

a. a new kind of location list entry that specifies a pair of view
numbers, that must be placed e.g. right before a bounded location
description entry,

b. several new kinds of location list entries, each corresponding to an
existing bounded location description entry kind augmented with a pair
of view numbers


Now, my intent has been to make this extension backward-compatible, so
that debug info consumers unaware of view numbers can still use the
location lists.  I had hoped the newly-introduced entry kind identifiers
could help accomplish this, but AFAICT it doesn't: a consumer wouldn't
know how to skip an entry of an unknown kind, so adding any extended
entry kind would make the location list unusable from that point on, and
consumers might be well-justified to disregard the whole thing.

Is that so?  If loclists are really not supposed to be experimentally
extensible, introducing a new experimental kind will be a bit of a
challenge, even if it is proposed or even accepted for inclusion in
future versions of the standard.

With that, I'm leaning towards sticking with a separate attribute and
viewlist form, as proposed before, in spite of the awkwardness of the
matching list entries, instead of trying to fit the view numbers in
extended loclist entries.


Now, of course, if this becomes part of the standard, it might make more
sense to encode the view numbers in the location list, even if it would
make location lists of this new version of the standard incompatible
with location lists of earlier versions.

So, before I elaborate either form, I'd appreciate feedback on which
would be the preferred way to introduce this sort of extension:
introduce new loclist kind or kinds, in spite of breaking backward
compatibility of lists, or use a new attribute and list form to hold
view numbers?

Thanks in advance,

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


From aprantl@apple.com  Fri Mar 17 20:18:34 2017
From: aprantl@apple.com (Adrian Prantl)
Date: Fri, 17 Mar 2017 13:18:34 -0700
Subject: [Dwarf-Discuss] Semantics of DW_OP_(b)reg
Message-ID: <D9660636-941F-4177-A6B2-258D36CC871C@apple.com>

I have a couple of questions regarding the semantics of DW_OP_reg(x) and DW_OP_breg(x). LLVM's DWARF expression generator (which was written with DWARF 2 in mind) treats DW_OP_breg as synonymous with DW_OP_reg DW_OP_deref, but I get the impression that that may not be correct in DWARF 4+. However, before making any changes to LLVM, I wanted to make sure that I actually understand the semantics correctly.

My understanding is that the presence of DW_OP_stack_value (or DW_OP_implicit_value) is what distinguishes a memory location description (2.6.1.1.2; top of stack is the address of our value) from an implicit location description (2.6.1.1.4; top of stack is the value itself). A location description with only a DW_OP_reg is a register location description (2.6.1.1.3 the value is the contents of the register).

>From reading Section 2.6.1.1, it sounds as if DW_OP_reg should only be used when it is the only operation in an expression. The non-normative text in 2.6.1.1.4 seems to confirm that, but the language is vague and avoids making any reference to the DWARF expression stack:
> These operations name a register location. To fetch the contents of a register, it is
> necessary to use one of the register based addressing operations, such as DW_OP_bregx

What is the effect of DW_OP_reg on the DWARF expression stack? Is it legal to use DW_OP_reg in an implicit or memory location description? I'm asking because it looks like the semantics of DW_OP_reg in terms of the stack are never described, but it is used in an example in Appendix D as part of an implicit location description (DW_OP_entry_value 1 DW_OP_reg1 DW_OP_stack_value).

Assuming that the example is correct, and that it is legal to use DW_OP_reg inside a memory or implicit location description, below are a couple of pointed questions:

Are these two expressions equivalent?
1. DW_OP_breg1 0 DW_OP_breg2 0 DW_OP_plus DW_OP_stack_value
2. DW_OP_reg1    DW_OP_reg2    DW_OP_plus DW_OP_stack_value

Are these two expressions equivalent?
1. DW_OP_reg1     ; is this a register location?
2. DW_OP_breg1 0  ; is this a memory location?

Are these two expressions equivalent?
1. DW_OP_reg1 DW_OP_deref ; is this a memory location?
2. DW_OP_breg1 0

Are these two expressions equivalent?
1. DW_OP_reg1
2. DW_OP_breg1 0 DW_OP_stack_value

Are these two expressions equivalent?
1. DW_OP_reg1 DW_OP_deref DW_OP_stack_value
2. DW_OP_breg1 0

Are these two expressions equivalent?
3. DW_OP_breg1 0 DW_OP_deref DW_OP_stack_value
2. DW_OP_breg1 0


thanks,
adrian


From davea42@linuxmail.org  Fri Mar 17 21:49:24 2017
From: davea42@linuxmail.org (David Anderson)
Date: Fri, 17 Mar 2017 14:49:24 -0700
Subject: [Dwarf-Discuss] Semantics of DW_OP_(b)reg
In-Reply-To: <D9660636-941F-4177-A6B2-258D36CC871C@apple.com>
References: <D9660636-941F-4177-A6B2-258D36CC871C@apple.com>
Message-ID: <8b927e57-40a8-28e8-873a-7f25994e238d@linuxmail.org>

On 03/17/2017 01:18 PM, Adrian Prantl wrote:
> Are these two expressions equivalent?
> 1. DW_OP_breg1 0 DW_OP_breg2 0 DW_OP_plus DW_OP_stack_value
> 2. DW_OP_reg1    DW_OP_reg2    DW_OP_plus DW_OP_stack_value

In DW4 (DW5 has same text)
These operations name a register location. To fetch the contents of a
register, it is necessary to
use one of the register based addressing operations, such as DW_OP_bregx
(see Section
2.5.1.2).

To me that means that 2. above cannot work.

In 1. the value of   DW_OP_breg1 0
(for example) is  pushed on the stack.

Can someone point out
where the standard (4 or 5 or?) states the push happens?
Ah yes: DW5:

2.5.1.2 Register Values

The following operations push a value onto the stack
that is either the contents of a register or the result
of adding the contents of a register to a given
signed offset. DW_OP_regval_type pushes the
contents of the register together with the given
base type, while the other operations push the
result of adding the contents of a register
to a given signed offset together with the generic type.

Notice that DW_OP_reg<n> is NOT in the list where something
gets pushed on the stack.

Comments/correction?
DavidA.


From aprantl@apple.com  Fri Mar 17 21:54:50 2017
From: aprantl@apple.com (Adrian Prantl)
Date: Fri, 17 Mar 2017 14:54:50 -0700
Subject: [Dwarf-Discuss] Semantics of DW_OP_(b)reg
In-Reply-To: <8b927e57-40a8-28e8-873a-7f25994e238d@linuxmail.org>
References: <D9660636-941F-4177-A6B2-258D36CC871C@apple.com>
	<8b927e57-40a8-28e8-873a-7f25994e238d@linuxmail.org>
Message-ID: <9C2A7757-84A0-4771-937F-3A27FE3C081F@apple.com>


> On Mar 17, 2017, at 2:49 PM, David Anderson <davea42 at linuxmail.org> wrote:
> 
> On 03/17/2017 01:18 PM, Adrian Prantl wrote:
>> Are these two expressions equivalent?
>> 1. DW_OP_breg1 0 DW_OP_breg2 0 DW_OP_plus DW_OP_stack_value
>> 2. DW_OP_reg1    DW_OP_reg2    DW_OP_plus DW_OP_stack_value
> 
> In DW4 (DW5 has same text)
> These operations name a register location. To fetch the contents of a
> register, it is necessary to
> use one of the register based addressing operations, such as DW_OP_bregx
> (see Section
> 2.5.1.2).
> 
> To me that means that 2. above cannot work.
> 
> In 1. the value of   DW_OP_breg1 0
> (for example) is  pushed on the stack.
> 
> Can someone point out
> where the standard (4 or 5 or?) states the push happens?
> Ah yes: DW5:
> 
> 2.5.1.2 Register Values
> 
> The following operations push a value onto the stack
> that is either the contents of a register or the result
> of adding the contents of a register to a given
> signed offset. DW_OP_regval_type pushes the
> contents of the register together with the given
> base type, while the other operations push the
> result of adding the contents of a register
> to a given signed offset together with the generic type.
> 
> Notice that DW_OP_reg<n> is NOT in the list where something
> gets pushed on the stack.
> 
> Comments/correction?
> DavidA.

Would you say that the example in Appendix D, pg 291, line 23
  DW_OP_entry_value 1 DW_OP_reg1 DW_OP_stack_value
is incorrect, because DW_OP_ref is not allowed outside of a register location description?

-- adrian


From davea42@linuxmail.org  Fri Mar 17 22:26:01 2017
From: davea42@linuxmail.org (David Anderson)
Date: Fri, 17 Mar 2017 15:26:01 -0700
Subject: [Dwarf-Discuss] Semantics of DW_OP_(b)reg
In-Reply-To: <9C2A7757-84A0-4771-937F-3A27FE3C081F@apple.com>
References: <D9660636-941F-4177-A6B2-258D36CC871C@apple.com>
	<8b927e57-40a8-28e8-873a-7f25994e238d@linuxmail.org>
	<9C2A7757-84A0-4771-937F-3A27FE3C081F@apple.com>
Message-ID: <3a419e77-b6e4-807a-f4df-5e3997c3afff@linuxmail.org>

On 03/17/2017 02:54 PM, Adrian Prantl wrote:
> Would you say that the example in Appendix D, pg 291, line 23
>   DW_OP_entry_value 1 DW_OP_reg1 DW_OP_stack_value
> is incorrect, because DW_OP_ref is not allowed outside of a register location description?

DW5 2.5.1.7:

DW_OP_entry_value
The DW_OP_entry_value operation pushes the value that the described
location held upon entering the current subprogram. It has two operands: an
unsigned LEB128 length, followed by a block containing a DWARF
expression or a register location description (see Section 2.6.1.1.3 on
page 39).
The length operand specifies the length in bytes of the block. If the block
contains a DWARF expression, the DWARF expression is evaluated as if it
had been evaluated upon entering the current subprogram. The DWARF
expression assumes no values are present on the DWARF stack initially and
results in exactly one value being pushed on the DWARF stack when
completed. If the block contains a register location description,
DW_OP_entry_value pushes the value that register had upon entering the
current subprogram.



Now this is interesting wording. Because it says 'described location'.
I think there is a strong case for arguing that a register name does
describe a 'thing' that held a value.   And it says 'register location
description' which is precisely 2.6.1.1.3  which reaffirms that
idea. .

    DW_OP_entry_value 1 DW_OP_reg1 
pushes a value on the stack
and if was handed a register name it must find the contents
of that register and push it.

DW_OP_stack_value then notifies (the debugger) that 
the object value is on the stack (it does not pop or push anything).

So the example does seem (to me) to be correct DWARF.
Quite a special case!

DavidA.



From aprantl@apple.com  Mon Mar 20 16:07:31 2017
From: aprantl@apple.com (Adrian Prantl)
Date: Mon, 20 Mar 2017 09:07:31 -0700
Subject: [Dwarf-Discuss] Semantics of DW_OP_(b)reg
In-Reply-To: <3a419e77-b6e4-807a-f4df-5e3997c3afff@linuxmail.org>
References: <D9660636-941F-4177-A6B2-258D36CC871C@apple.com>
	<8b927e57-40a8-28e8-873a-7f25994e238d@linuxmail.org>
	<9C2A7757-84A0-4771-937F-3A27FE3C081F@apple.com>
	<3a419e77-b6e4-807a-f4df-5e3997c3afff@linuxmail.org>
Message-ID: <9C92B211-9CF6-44F9-8F58-C251B2018E70@apple.com>


> On Mar 17, 2017, at 3:26 PM, David Anderson <davea42 at linuxmail.org> wrote:
> 
> On 03/17/2017 02:54 PM, Adrian Prantl wrote:
>> Would you say that the example in Appendix D, pg 291, line 23
>>  DW_OP_entry_value 1 DW_OP_reg1 DW_OP_stack_value
>> is incorrect, because DW_OP_ref is not allowed outside of a register location description?
> 
> DW5 2.5.1.7:
> 
> DW_OP_entry_value
> The DW_OP_entry_value operation pushes the value that the described
> location held upon entering the current subprogram. It has two operands: an
> unsigned LEB128 length, followed by a block containing a DWARF
> expression or a register location description (see Section 2.6.1.1.3 on
> page 39).
> The length operand specifies the length in bytes of the block. If the block
> contains a DWARF expression, the DWARF expression is evaluated as if it
> had been evaluated upon entering the current subprogram. The DWARF
> expression assumes no values are present on the DWARF stack initially and
> results in exactly one value being pushed on the DWARF stack when
> completed. If the block contains a register location description,
> DW_OP_entry_value pushes the value that register had upon entering the
> current subprogram.
> 
> 
> 
> Now this is interesting wording. Because it says 'described location'.
> I think there is a strong case for arguing that a register name does
> describe a 'thing' that held a value.   And it says 'register location
> description' which is precisely 2.6.1.1.3  which reaffirms that
> idea. .
> 
>    DW_OP_entry_value 1 DW_OP_reg1 
> pushes a value on the stack
> and if was handed a register name it must find the contents
> of that register and push it.
> 
> DW_OP_stack_value then notifies (the debugger) that 
> the object value is on the stack (it does not pop or push anything).
> 
> So the example does seem (to me) to be correct DWARF.
> Quite a special case!

I see. It is legal because of the special wording in 2.5.1.7 that allows a register location description to be the argument of DW_OP_entry_value.

-- adrian


> 
> DavidA.
> 



From aprantl@apple.com  Mon Mar 20 16:23:36 2017
From: aprantl@apple.com (Adrian Prantl)
Date: Mon, 20 Mar 2017 09:23:36 -0700
Subject: [Dwarf-Discuss] Semantics of DW_OP_(b)reg
In-Reply-To: <8b927e57-40a8-28e8-873a-7f25994e238d@linuxmail.org>
References: <D9660636-941F-4177-A6B2-258D36CC871C@apple.com>
	<8b927e57-40a8-28e8-873a-7f25994e238d@linuxmail.org>
Message-ID: <1A3E2B4D-5ADC-4BCA-BE55-ABFD677F1196@apple.com>


> On Mar 17, 2017, at 2:49 PM, David Anderson <davea42 at linuxmail.org> wrote:
> 
> On 03/17/2017 01:18 PM, Adrian Prantl wrote:
>> Are these two expressions equivalent?
>> 1. DW_OP_breg1 0 DW_OP_breg2 0 DW_OP_plus DW_OP_stack_value
>> 2. DW_OP_reg1    DW_OP_reg2    DW_OP_plus DW_OP_stack_value
> 
> In DW4 (DW5 has same text)
> These operations name a register location. To fetch the contents of a
> register, it is necessary to
> use one of the register based addressing operations, such as DW_OP_bregx
> (see Section
> 2.5.1.2).
> 
> To me that means that 2. above cannot work.

Thanks for the clarification!

To summarize in my own words: in DWARF 4+, a DW_OP_reg(x) may only appear in a register location description, which implies that it must either be the only operation in an expression, or embedded inside an expression that takes a register location description as an argument, such as DW_OP_entry_value.

In particular, this means that these two location descriptions are equivalent:
1. DW_OP_breg1 0 DW_OP_stack_value ; implicit location description
2. DW_OP_reg1                      ; register location description

This is illegal:
1. DW_OP_reg1 DW_OP_deref

And these are also equivalent:
1. DW_OP_breg1 0 DW_OP_deref DW_OP_stack_value ; implicit loc. desc.
2. DW_OP_breg1 0                               ; memory loc. desc.

Let me know if I got anything wrong.
-- adrian


> 
> In 1. the value of   DW_OP_breg1 0
> (for example) is  pushed on the stack.
> 
> Can someone point out
> where the standard (4 or 5 or?) states the push happens?
> Ah yes: DW5:
> 
> 2.5.1.2 Register Values
> 
> The following operations push a value onto the stack
> that is either the contents of a register or the result
> of adding the contents of a register to a given
> signed offset. DW_OP_regval_type pushes the
> contents of the register together with the given
> base type, while the other operations push the
> result of adding the contents of a register
> to a given signed offset together with the generic type.
> 
> Notice that DW_OP_reg<n> is NOT in the list where something
> gets pushed on the stack.
> 
> Comments/correction?
> DavidA.
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org



From davea42@linuxmail.org  Mon Mar 20 16:48:18 2017
From: davea42@linuxmail.org (David Anderson)
Date: Mon, 20 Mar 2017 09:48:18 -0700
Subject: [Dwarf-Discuss] Semantics of DW_OP_(b)reg
In-Reply-To: <9C92B211-9CF6-44F9-8F58-C251B2018E70@apple.com>
References: <D9660636-941F-4177-A6B2-258D36CC871C@apple.com>
	<8b927e57-40a8-28e8-873a-7f25994e238d@linuxmail.org>
	<9C2A7757-84A0-4771-937F-3A27FE3C081F@apple.com>
	<3a419e77-b6e4-807a-f4df-5e3997c3afff@linuxmail.org>
	<9C92B211-9CF6-44F9-8F58-C251B2018E70@apple.com>
Message-ID: <820795bc-d74b-58cc-2990-ab6caae19501@linuxmail.org>

On 03/17/2017 09:07 AM,  I wrote
> Now this is interesting wording. Because it says 'described location'.
> I think there is a strong case for arguing that a register name does
> describe a 'thing' that held a value.   And it says 'register location
> description' which is precisely 2.6.1.1.3  which reaffirms that
> idea. .

Having said the above I think this use of 'register location description'
is an example of a place in the Dwarf5 standard
where a link (to 2.6.1.1.3 ) would be a distinct improvement.

An improvement because it draws attention to that phrase
as having a very specific interpretation in the standard,
making the reader's job easier without adding visible text.


DavidA.


From jakub@redhat.com  Mon Mar 20 16:59:21 2017
From: jakub@redhat.com (Jakub Jelinek)
Date: Mon, 20 Mar 2017 17:59:21 +0100
Subject: [Dwarf-Discuss] Semantics of DW_OP_(b)reg
In-Reply-To: <1A3E2B4D-5ADC-4BCA-BE55-ABFD677F1196@apple.com>
References: <D9660636-941F-4177-A6B2-258D36CC871C@apple.com>
	<8b927e57-40a8-28e8-873a-7f25994e238d@linuxmail.org>
	<1A3E2B4D-5ADC-4BCA-BE55-ABFD677F1196@apple.com>
Message-ID: <20170320165921.GK11094@tucnak>

On Mon, Mar 20, 2017 at 09:23:36AM -0700, Adrian Prantl wrote:
> 
> > On Mar 17, 2017, at 2:49 PM, David Anderson <davea42 at linuxmail.org> wrote:
> > 
> > On 03/17/2017 01:18 PM, Adrian Prantl wrote:
> >> Are these two expressions equivalent?
> >> 1. DW_OP_breg1 0 DW_OP_breg2 0 DW_OP_plus DW_OP_stack_value
> >> 2. DW_OP_reg1    DW_OP_reg2    DW_OP_plus DW_OP_stack_value
> > 
> > In DW4 (DW5 has same text)
> > These operations name a register location. To fetch the contents of a
> > register, it is necessary to
> > use one of the register based addressing operations, such as DW_OP_bregx
> > (see Section
> > 2.5.1.2).
> > 
> > To me that means that 2. above cannot work.
> 
> Thanks for the clarification!
> 
> To summarize in my own words: in DWARF 4+, a DW_OP_reg(x) may only appear in a register location description, which implies that it must either be the only operation in an expression, or embedded inside an expression that takes a register location description as an argument, such as DW_OP_entry_value.
> 
> In particular, this means that these two location descriptions are equivalent:
> 1. DW_OP_breg1 0 DW_OP_stack_value ; implicit location description
> 2. DW_OP_reg1                      ; register location description

They are not equivalent.  The former is, the value of this and this can be
computed by adding 0 to the value of register 1, the latter the value lives
in the register 1.  To the debug info consumer, 1. is something you can't
really modify if you e.g. want to change the value of some variable, while
2. can be modified.
> 
> This is illegal:
> 1. DW_OP_reg1 DW_OP_deref

Yeah, illegal.

> And these are also equivalent:
> 1. DW_OP_breg1 0 DW_OP_deref DW_OP_stack_value ; implicit loc. desc.
> 2. DW_OP_breg1 0                               ; memory loc. desc.

Again, same difference as above, the former can't be modified, the latter
can.

	Jakub


From aprantl@apple.com  Mon Mar 20 17:04:10 2017
From: aprantl@apple.com (Adrian Prantl)
Date: Mon, 20 Mar 2017 10:04:10 -0700
Subject: [Dwarf-Discuss] Semantics of DW_OP_(b)reg
In-Reply-To: <20170320165921.GK11094@tucnak>
References: <D9660636-941F-4177-A6B2-258D36CC871C@apple.com>
	<8b927e57-40a8-28e8-873a-7f25994e238d@linuxmail.org>
	<1A3E2B4D-5ADC-4BCA-BE55-ABFD677F1196@apple.com>
	<20170320165921.GK11094@tucnak>
Message-ID: <072DF38B-49DB-4232-B4F1-8C103BCAD433@apple.com>


> On Mar 20, 2017, at 9:59 AM, Jakub Jelinek <jakub at redhat.com> wrote:
> 
> On Mon, Mar 20, 2017 at 09:23:36AM -0700, Adrian Prantl wrote:
>> 
>>> On Mar 17, 2017, at 2:49 PM, David Anderson <davea42 at linuxmail.org> wrote:
>>> 
>>> On 03/17/2017 01:18 PM, Adrian Prantl wrote:
>>>> Are these two expressions equivalent?
>>>> 1. DW_OP_breg1 0 DW_OP_breg2 0 DW_OP_plus DW_OP_stack_value
>>>> 2. DW_OP_reg1    DW_OP_reg2    DW_OP_plus DW_OP_stack_value
>>> 
>>> In DW4 (DW5 has same text)
>>> These operations name a register location. To fetch the contents of a
>>> register, it is necessary to
>>> use one of the register based addressing operations, such as DW_OP_bregx
>>> (see Section
>>> 2.5.1.2).
>>> 
>>> To me that means that 2. above cannot work.
>> 
>> Thanks for the clarification!
>> 
>> To summarize in my own words: in DWARF 4+, a DW_OP_reg(x) may only appear in a register location description, which implies that it must either be the only operation in an expression, or embedded inside an expression that takes a register location description as an argument, such as DW_OP_entry_value.
>> 
>> In particular, this means that these two location descriptions are equivalent:
>> 1. DW_OP_breg1 0 DW_OP_stack_value ; implicit location description
>> 2. DW_OP_reg1                      ; register location description
> 
> They are not equivalent.  The former is, the value of this and this can be
> computed by adding 0 to the value of register 1, the latter the value lives
> in the register 1.  To the debug info consumer, 1. is something you can't
> really modify if you e.g. want to change the value of some variable, while
> 2. can be modified.

Thanks! That is of course an important distinction for the debugger. It also explains why register location descriptions exist even though they appear to be redundant with the more general implicit descriptions at first.

-- adrian

>> 
>> This is illegal:
>> 1. DW_OP_reg1 DW_OP_deref
> 
> Yeah, illegal.
> 
>> And these are also equivalent:
>> 1. DW_OP_breg1 0 DW_OP_deref DW_OP_stack_value ; implicit loc. desc.
>> 2. DW_OP_breg1 0                               ; memory loc. desc.
> 
> Again, same difference as above, the former can't be modified, the latter
> can.
> 
> 	Jakub



From dyoung+dwarf@pobox.com  Tue Mar 21 21:43:27 2017
From: dyoung+dwarf@pobox.com (David Young)
Date: Tue, 21 Mar 2017 16:43:27 -0500
Subject: [Dwarf-Discuss] evaluator for DWARF expressions in C?
Message-ID: <20170321214327.GA13866@pobox.com>

I have been searching the web for a C implementation of the stack
machine that evaluates DWARF expressions, hoping to find one with a
liberal license (BSD or similar).  I'm not finding one.  Does anything
like that exist?

Dave 

-- 
David Young
dyoung at pobox.com    Urbana, IL    (217) 721-9981


