(CCing gcc-patches because of the change in include/dwarf2.h)
On 2018-08-23 13:35, John Darrington wrote:
* include/dwarf2.h (enum dwarf_unit_type)[DW_EH_PE_udata3]: New member.
* gdb/dwarf2-frame.c (encoding_for_size): Deal with case 3.
(read_encoded_value): Deal with case DW_EH_PE_udata3
---
gdb/dwarf2-frame.c | 7 ++++++-
include/dwarf2.h | 5 ++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/gdb/dwarf2-frame.c b/gdb/dwarf2-frame.c
index f7dc820f4d..b329e34997 100644
--- a/gdb/dwarf2-frame.c
+++ b/gdb/dwarf2-frame.c
@@ -1527,12 +1527,14 @@ encoding_for_size (unsigned int size)
{
case 2:
return DW_EH_PE_udata2;
+ case 3:
+ return DW_EH_PE_udata3;
case 4:
return DW_EH_PE_udata4;
case 8:
return DW_EH_PE_udata8;
default:
- internal_error (__FILE__, __LINE__, _("Unsupported address
size"));
+ internal_error (__FILE__, __LINE__, _("Unsupported address size
%d"), size);
}
}
@@ -1605,6 +1607,9 @@ read_encoded_value (struct comp_unit *unit,
gdb_byte encoding,
case DW_EH_PE_udata2:
*bytes_read_ptr += 2;
return (base + bfd_get_16 (unit->abfd, (bfd_byte *) buf));
+ case DW_EH_PE_udata3:
+ *bytes_read_ptr += 3;
+ return (base + bfd_get_24 (unit->abfd, (bfd_byte *) buf));
case DW_EH_PE_udata4:
*bytes_read_ptr += 4;
return (base + bfd_get_32 (unit->abfd, (bfd_byte *) buf));
diff --git a/include/dwarf2.h b/include/dwarf2.h
index cf0039a92a..05c328057b 100644
--- a/include/dwarf2.h
+++ b/include/dwarf2.h
@@ -474,11 +474,14 @@ enum dwarf_unit_type
#define DW_EH_PE_udata2 0x02
#define DW_EH_PE_udata4 0x03
#define DW_EH_PE_udata8 0x04
+
+#define DW_EH_PE_udata3 0x05
+
+#define DW_EH_PE_signed 0x08
#define DW_EH_PE_sleb128 0x09
#define DW_EH_PE_sdata2 0x0A
#define DW_EH_PE_sdata4 0x0B
#define DW_EH_PE_sdata8 0x0C
-#define DW_EH_PE_signed 0x08
#define DW_EH_PE_pcrel 0x10
#define DW_EH_PE_textrel 0x20
This file is owned by GCC (see the MAINTAINERS file at the top of
binutils-gdb). To get a modification in it, you would need to provide a
patch to gcc, then we can import the change in binutils-gdb.
I am not too sure who is responsible for allocating these values, as
they are not from the DWARF standard. At the very least, there should
be a comment to say what architecture uses this non-standard value. Is
there also a gcc port you are planning to upstream, that would use this
value?
Simon