On Feb 13 2018, Alexandre Oliva wrote:
> The patch I posted last night should work around this problem, in that
> it will disable LVU by default if the assembler doesn't support .loc
> views, and then you won't get this error any more, unless you explicitly
> ask for location
On Feb 12, 2018, Andreas Schwab wrote:
> On Feb 12 2018, Alexandre Oliva wrote:
>> On Feb 11, 2018, Andreas Schwab wrote:
>>
>>> On Feb 09 2018, Alexandre Oliva wrote:
>>
+ if (list_head->vl_symbol &&
On Feb 12 2018, Alexandre Oliva wrote:
> On Feb 11, 2018, Andreas Schwab wrote:
>
>> On Feb 09 2018, Alexandre Oliva wrote:
>
>>> + if (list_head->vl_symbol && dwarf2out_locviews_in_attribute ())
>>> +{
>>> +
On Feb 11, 2018, Andreas Schwab wrote:
> On Feb 09 2018, Alexandre Oliva wrote:
>> + if (list_head->vl_symbol && dwarf2out_locviews_in_attribute ())
>> +{
>> + ASM_OUTPUT_LABEL (asm_out_file, list_head->vl_symbol);
> That needs to use
On Feb 11, 2018, Andreas Schwab wrote:
>> + if (list_head->vl_symbol && dwarf2out_locviews_in_attribute ())
>> +{
>> + ASM_OUTPUT_LABEL (asm_out_file, list_head->vl_symbol);
> That needs to use ASM_OUTPUT_DEBUG_LABEL.
There's another use of the same macro that
On Feb 09 2018, Alexandre Oliva wrote:
> @@ -9681,34 +9978,85 @@ gen_llsym (dw_loc_list_ref list)
> static void
> output_loc_list (dw_loc_list_ref list_head)
> {
> + int vcount = 0, lcount = 0;
> +
>if (list_head->emitted)
> return;
>list_head->emitted = true;
On Feb 09 2018, Alexandre Oliva wrote:
> [LVU] Introduce location views
>
> This patch introduces an option to enable the generation of location
> views along with location lists. The exact format depends on the
> DWARF version: it can be a separate attribute
On Feb 8, 2018, Jason Merrill wrote:
> On Thu, Feb 8, 2018 at 7:56 AM, Alexandre Oliva wrote:
>> On Feb 7, 2018, Jason Merrill wrote:
>>
>>> OK, that makes sense. But I'm still uncomfortable with choosing an
>>> existing opcode for
On Feb 8, 2018, Jason Merrill wrote:
> On 02/07/2018 02:36 AM, Alexandre Oliva wrote:
>> +/* Output symbol LAB1 as an unsigned LEB128 quantity. */
> Let's mention here that the value of LAB1 must be an assemble-time
> constant (such as a view counter), since we can't have
On 02/07/2018 02:36 AM, Alexandre Oliva wrote:
+/* Output symbol LAB1 as an unsigned LEB128 quantity. */
Let's mention here that the value of LAB1 must be an assemble-time
constant (such as a view counter), since we can't have LEB128 relocations.
With that, the patch looks OK.
Jason
On Thu, Feb 8, 2018 at 7:56 AM, Alexandre Oliva wrote:
> On Feb 7, 2018, Jason Merrill wrote:
>
>> OK, that makes sense. But I'm still uncomfortable with choosing an
>> existing opcode for that purpose, which previously would have been
>> chosen just for
On Feb 7, 2018, Jason Merrill wrote:
> OK, that makes sense. But I'm still uncomfortable with choosing an
> existing opcode for that purpose, which previously would have been
> chosen just for reasons of encoding complexity and size.
Well, there's a good reason we didn't
On 02/06/2018 11:02 PM, Alexandre Oliva wrote:
On Feb 6, 2018, Jason Merrill wrote:
On 12/11/2017 09:52 PM, Alexandre Oliva wrote:
Why do we need to use a non-zero view identifier for a zero view? Why
can't we always use 0 instead of the bitmap?
We assign view ids
On Jan 25, 2018, Alexandre Oliva wrote:
> On Jan 24, 2018, Jakub Jelinek wrote:
>> On Tue, Dec 12, 2017 at 12:52:18AM -0200, Alexandre Oliva wrote:
>>> +DW_LLE_GNU_view_pair = 0x09,
>>> +#define DW_LLE_view_pair DW_LLE_GNU_view_pair
>> This looks wrong.
Here's the updated version of the LVU patch, integrating changes
requested or proposed by yourself and by Jakub.
for include/ChangeLog
* dwarf2.def (DW_AT_GNU_locviews): New.
* dwarf2.h (enum dwarf_location_list_entry_type): Add
DW_LLE_GNU_view_pair.
Here's an incremental patch with the changes I made in response to your
requests. I'll post the complete updated patch momentarily.
diff --git a/gcc/common.opt b/gcc/common.opt
index 55d9cdd714ff..7e024fdab124 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2957,9 +2957,12 @@ Common Driver
On Jan 30, 2018, Richard Sandiford wrote:
>> But it is my understanding that both of the following are correct:
>>
>> return (verylongcondition
>> && otherlongcondition__);
>>
>> return
On Feb 6, 2018, Jason Merrill wrote:
> On 12/11/2017 09:52 PM, Alexandre Oliva wrote:
>> +/* output symbol LAB1 as an unsigned LEB128 quantity. */
>> +
>> +void
>> +dw2_asm_output_symname_uleb128 (const char *lab1 ATTRIBUTE_UNUSED,
>> +const char
On 12/11/2017 09:52 PM, Alexandre Oliva wrote:
+/* output symbol LAB1 as an unsigned LEB128 quantity. */
+
+void
+dw2_asm_output_symname_uleb128 (const char *lab1 ATTRIBUTE_UNUSED,
+ const char *comment, ...)
I'm having trouble understanding the use of symbols
Alexandre Oliva writes:
> On Jan 26, 2018, Jakub Jelinek wrote:
>
>> Having to tweak debug info consumers so that they treat DW_LLE_* of 9
>> one way for .debug_loclist of version 5 and another way for .debug_loclist
>> of version 6 isn't a good idea.
>
>
On Jan 26, 2018, Jakub Jelinek wrote:
> Having to tweak debug info consumers so that they treat DW_LLE_* of 9
> one way for .debug_loclist of version 5 and another way for .debug_loclist
> of version 6 isn't a good idea.
Maybe we don't have to do that. The reason I
On Thu, Jan 25, 2018 at 05:58:37PM -0200, Alexandre Oliva wrote:
> > This looks wrong. The proposal has not been accepted yet, so you
> > really can't know if DW_LLE_view_pair will be like that or whether it
> > will have value of 9. Unfortunately, the DWARF standard doesn't specify a
> > vendor
On Jan 24, 2018, Jakub Jelinek wrote:
> On Tue, Dec 12, 2017 at 12:52:18AM -0200, Alexandre Oliva wrote:
>> --- a/include/dwarf2.h
>> +++ b/include/dwarf2.h
>> @@ -298,6 +298,14 @@ enum dwarf_location_list_entry_type
>> DW_LLE_start_end = 0x07,
>> DW_LLE_start_length = 0x08,
>>
On Tue, Dec 12, 2017 at 12:52:18AM -0200, Alexandre Oliva wrote:
> --- a/include/dwarf2.h
> +++ b/include/dwarf2.h
> @@ -298,6 +298,14 @@ enum dwarf_location_list_entry_type
> DW_LLE_start_end = 0x07,
> DW_LLE_start_length = 0x08,
>
> +/*
>
On Dec 11, 2017, Jeff Law wrote:
> On 11/09/2017 07:34 PM, Alexandre Oliva wrote:
>> This patch introduces an option to enable the generation of location
>> views along with location lists. The exact format depends on the
>> void
>> +dw2_asm_output_symname_uleb128 (const char
On 11/09/2017 07:34 PM, Alexandre Oliva wrote:
> This patch introduces an option to enable the generation of location
> views along with location lists. The exact format depends on the
> DWARF version: it can be a separate attribute (DW_AT_GNU_locviews) or
> (DW_LLE_view_pair) entries in DWARF5+
On Nov 13, 2017, Richard Biener wrote:
> What does final.c need langhooks for?
Thanks for catching this.
At some point I had a check on whether there could be being stmt markers
emitted by the language, but that's long gone, in part because of LTO;
that's now
On Fri, Nov 10, 2017 at 3:34 AM, Alexandre Oliva wrote:
> This patch introduces an option to enable the generation of location
> views along with location lists. The exact format depends on the
> DWARF version: it can be a separate attribute (DW_AT_GNU_locviews) or
>
This patch introduces an option to enable the generation of location
views along with location lists. The exact format depends on the
DWARF version: it can be a separate attribute (DW_AT_GNU_locviews) or
(DW_LLE_view_pair) entries in DWARF5+ loclists.
Line number tables are also affected. If
29 matches
Mail list logo