[patch+8.0] DWARF-5 Fix DW_FORM_implicit_const

[patch+8.0] DWARF-5 Fix DW_FORM_implicit_const

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 234 bytes --]

Hi,

the other possibility is to patch attr_form_is_constant() and
dwarf2_get_attr_constant_value(), I do not see what is better.

It fixes for example:
	FAIL: gdb.base/constvars.exp: ptype logical

for -gdwarf-4 vs. -gdwarf-5.


Jan

[-- Attachment #2: implicit.patch --]
[-- Type: text/plain, Size: 566 bytes --]

gdb/ChangeLog
2017-06-22  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* dwarf2read.c (read_attribute_value) <DW_FORM_implicit_const>: Set it
	as DW_FORM_sdata.

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 2369d4b..77f870d 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -16775,6 +16775,7 @@ read_attribute_value (const struct die_reader_specs *reader,
 				       info_ptr);
       break;
     case DW_FORM_implicit_const:
+      attr->form = DW_FORM_sdata;
       DW_SND (attr) = implicit_const;
       break;
     case DW_FORM_GNU_addr_index:

Re: [patch+8.0] DWARF-5 Fix DW_FORM_implicit_const

[Pedro Alves]

Hi Jan,

On 06/22/2017 09:33 PM, Jan Kratochvil wrote:
> 
> the other possibility is to patch attr_form_is_constant() and
> dwarf2_get_attr_constant_value(), I do not see what is better.

Wouldn't that be more direct and to the point?  If I'm imagining
that version of the patch correctly, that'd seem like a
more obvious choice to me.  The proposed version looks like is
frobbing the form so that DW_FORM_sdata so that those two other
functions end up doing the right thing as side effect.  Right?
Is there some advantage to doing it the sdata way?  It kind of feels
like a hack, but maybe I'm missing something.

> 
> It fixes for example:
> 	FAIL: gdb.base/constvars.exp: ptype logical
> 
> for -gdwarf-4 vs. -gdwarf-5.
> 

Thanks,
Pedro Alves

[patchv2+8.0] DWARF-5 Fix DW_FORM_implicit_const

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

On Thu, 24 Aug 2017 01:08:01 +0200, Pedro Alves wrote:
> Wouldn't that be more direct and to the point?  If I'm imagining
> that version of the patch correctly, that'd seem like a
> more obvious choice to me.  The proposed version looks like is
> frobbing the form so that DW_FORM_sdata so that those two other
> functions end up doing the right thing as side effect.  Right?
> Is there some advantage to doing it the sdata way?  It kind of feels
> like a hack, but maybe I'm missing something.

Is this patch OK?

Regression tested on fedora-rawhide {x86_64,x86_64-m32,i686}.


Thanks,
Jan

[-- Attachment #2: dwarf5-implicit_form.patch --]
[-- Type: text/plain, Size: 2175 bytes --]

gdb/ChangeLog
2017-08-24  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* dwarf2read.c (dwarf2_const_value_attr, dump_die_shallow)
	(dwarf2_get_attr_constant_value, dwarf2_fetch_constant_bytes)
	(skip_form_bytes, attr_form_is_constant): Handle DW_FORM_implicit_const.

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 38228500ab..d4dd01b8b3 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -19499,6 +19499,7 @@ dwarf2_const_value_attr (const struct attribute *attr, struct type *type,
       break;
 
     case DW_FORM_sdata:
+    case DW_FORM_implicit_const:
       *value = DW_SND (attr);
       break;
 
@@ -20492,6 +20493,10 @@ dump_die_shallow (struct ui_file *f, int indent, struct die_info *die)
 	  fprintf_unfiltered (f, 
 			      "unexpected attribute form: DW_FORM_indirect");
 	  break;
+	case DW_FORM_implicit_const:
+	  fprintf_unfiltered (f, "constant: %s",
+			      plongest (DW_SND (&die->attrs[i])));
+	  break;
 	default:
 	  fprintf_unfiltered (f, "unsupported attribute form: %d.",
 		   die->attrs[i].form);
@@ -20583,7 +20588,7 @@ dwarf2_get_ref_die_offset (const struct attribute *attr)
 static LONGEST
 dwarf2_get_attr_constant_value (const struct attribute *attr, int default_value)
 {
-  if (attr->form == DW_FORM_sdata)
+  if (attr->form == DW_FORM_sdata || attr->form == DW_FORM_implicit_const)
     return DW_SND (attr);
   else if (attr->form == DW_FORM_udata
            || attr->form == DW_FORM_data1
@@ -20918,6 +20923,7 @@ dwarf2_fetch_constant_bytes (sect_offset sect_off,
       break;
 
     case DW_FORM_sdata:
+    case DW_FORM_implicit_const:
       type = die_type (die, cu);
       result = write_constant_as_bytes (obstack, byte_order,
 					type, DW_SND (attr), len);
@@ -21854,6 +21860,9 @@ skip_form_bytes (bfd *abfd, const gdb_byte *bytes, const gdb_byte *buffer_end,
 	}
       break;
 
+    case DW_FORM_implicit_const:
+      break;
+
     default:
       {
       complain:
@@ -22495,6 +22504,7 @@ attr_form_is_constant (const struct attribute *attr)
     case DW_FORM_data2:
     case DW_FORM_data4:
     case DW_FORM_data8:
+    case DW_FORM_implicit_const:
       return 1;
     default:
       return 0;

Re: [patchv2+8.0] DWARF-5 Fix DW_FORM_implicit_const

[Pedro Alves]

On 08/24/2017 01:57 PM, Jan Kratochvil wrote:
> On Thu, 24 Aug 2017 01:08:01 +0200, Pedro Alves wrote:
>> Wouldn't that be more direct and to the point?  If I'm imagining
>> that version of the patch correctly, that'd seem like a
>> more obvious choice to me.  The proposed version looks like is
>> frobbing the form so that DW_FORM_sdata so that those two other
>> functions end up doing the right thing as side effect.  Right?
>> Is there some advantage to doing it the sdata way?  It kind of feels
>> like a hack, but maybe I'm missing something.
> 
> Is this patch OK?

OK.

> 
> Regression tested on fedora-rawhide {x86_64,x86_64-m32,i686}.

Thanks,
Pedro Alves

[commit+8.0] DWARF-5 Fix DW_FORM_implicit_const

[Jan Kratochvil]

On Thu, 24 Aug 2017 14:59:44 +0200, Pedro Alves wrote:
> On 08/24/2017 01:57 PM, Jan Kratochvil wrote:
> > Is this patch OK?
> 
> OK.

Checked in:
	663c44ac4d4336e99c282705b1d289b365b273d3 master
	f74f69f45570ced87b9f778983a63157b551a129 gdb-8.0-branch
	https://sourceware.org/bugzilla/show_bug.cgi?id=22003


Jan