OK.
On Wed, Nov 2, 2016 at 10:18 AM, Jiong Wang wrote:
> On 02/11/16 13:42, Jakub Jelinek wrote:
>>
>> On Wed, Nov 02, 2016 at 01:26:48PM +, Jiong Wang wrote:
>>>
>>> -/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_EXPRESSION
>>> note. */
>>> +/* A subroutine of dwarf2out_frame_d
On 02/11/16 13:42, Jakub Jelinek wrote:
On Wed, Nov 02, 2016 at 01:26:48PM +, Jiong Wang wrote:
-/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_EXPRESSION note. */
+/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_EXPRESSION note.
*/
Too long line.
Hmm, it shows
On Wed, Nov 02, 2016 at 01:26:48PM +, Jiong Wang wrote:
> -/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_EXPRESSION note.
> */
> +/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_EXPRESSION note.
> */
Too long line.
> +/* RTL sequences inside PARALLEL are raw e
On 01/11/16 16:48, Jason Merrill wrote:
> It seems to me that a CFA_*expression note would never use target
> UNSPEC codes, and a DWARF UNSPEC would never appear outside of such a
> note, so we don't need to worry about conflicts.
Indeed.
DWARF UNSPEC is deeper inside DW_CFA_*expression note. M
On Tue, Nov 1, 2016 at 1:02 PM, Jiong Wang wrote:
> Besides this issue, do you think the PARALLEL + UNSPEC based approach to
> represent DWARF RAW expression is acceptable?
Yes.
Jason
On 01/11/16 16:48, Jason Merrill wrote:
On Tue, Nov 1, 2016 at 11:59 AM, Jiong Wang wrote:
On 01/11/16 15:24, Jason Merrill wrote:
On Tue, Nov 1, 2016 at 11:12 AM, Jiong Wang wrote:
On 31/10/16 19:50, Jason Merrill wrote:
On 10/21/2016 04:30 AM, Jiong Wang wrote:
All DW_OP_* of the expre
On Tue, Nov 1, 2016 at 11:59 AM, Jiong Wang wrote:
> On 01/11/16 15:24, Jason Merrill wrote:
>> On Tue, Nov 1, 2016 at 11:12 AM, Jiong Wang wrote:
>>> On 31/10/16 19:50, Jason Merrill wrote:
On 10/21/2016 04:30 AM, Jiong Wang wrote:
>
> All DW_OP_* of the expression are grouped toget
On 01/11/16 15:24, Jason Merrill wrote:
On Tue, Nov 1, 2016 at 11:12 AM, Jiong Wang wrote:
On 31/10/16 19:50, Jason Merrill wrote:
On 10/21/2016 04:30 AM, Jiong Wang wrote:
All DW_OP_* of the expression are grouped together inside the PARALLEL,
and those operations which don't have RTL mappin
On Tue, Nov 1, 2016 at 11:12 AM, Jiong Wang wrote:
> On 31/10/16 19:50, Jason Merrill wrote:
>>
>> On 10/21/2016 04:30 AM, Jiong Wang wrote:
>>>
>>> All DW_OP_* of the expression are grouped together inside the PARALLEL,
>>> and those operations which don't have RTL mapping are wrapped by
>>> UNSP
On 31/10/16 19:50, Jason Merrill wrote:
On 10/21/2016 04:30 AM, Jiong Wang wrote:
All DW_OP_* of the expression are grouped together inside the PARALLEL,
and those operations which don't have RTL mapping are wrapped by
UNSPEC. The parsing algorithm is simply something like:
foreach elem insi
On 10/21/2016 04:30 AM, Jiong Wang wrote:
All DW_OP_* of the expression are grouped together inside the PARALLEL,
and those operations which don't have RTL mapping are wrapped by
UNSPEC. The parsing algorithm is simply something like:
foreach elem inside PARALLEL
if (UNSPEC)
{
Currently, GCC only support DW_OP_EXPRESSION in dwarf module, this patch
extend the support to DW_OP_VAL_EXPRESSION which share the same code
mostly the same code with DW_OP_EXPRESSION.
Meanwhile the existed dwarf expression parser only allows expressions
which can be represented using GCC RTL.
12 matches
Mail list logo
