* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
@ 2020-09-30 18:19 ` wcohen at redhat dot com
2020-09-30 18:20 ` wcohen at redhat dot com
` (16 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: wcohen at redhat dot com @ 2020-09-30 18:19 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
--- Comment #1 from William Cohen <wcohen at redhat dot com> ---
Created attachment 12873
--> https://sourceware.org/bugzilla/attachment.cgi?id=12873&action=edit
the -g -O2 debuginfo
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
2020-09-30 18:19 ` [Bug default/26684] " wcohen at redhat dot com
@ 2020-09-30 18:20 ` wcohen at redhat dot com
2020-09-30 18:21 ` wcohen at redhat dot com
` (15 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: wcohen at redhat dot com @ 2020-09-30 18:20 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
--- Comment #2 from William Cohen <wcohen at redhat dot com> ---
Created attachment 12874
--> https://sourceware.org/bugzilla/attachment.cgi?id=12874&action=edit
the -gdwarf5 -O2 version of the binary
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
2020-09-30 18:19 ` [Bug default/26684] " wcohen at redhat dot com
2020-09-30 18:20 ` wcohen at redhat dot com
@ 2020-09-30 18:21 ` wcohen at redhat dot com
2020-09-30 18:22 ` wcohen at redhat dot com
` (14 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: wcohen at redhat dot com @ 2020-09-30 18:21 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
--- Comment #3 from William Cohen <wcohen at redhat dot com> ---
Created attachment 12875
--> https://sourceware.org/bugzilla/attachment.cgi?id=12875&action=edit
the -gdwarf5 -O2 debuginfo
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (2 preceding siblings ...)
2020-09-30 18:21 ` wcohen at redhat dot com
@ 2020-09-30 18:22 ` wcohen at redhat dot com
2020-10-01 16:01 ` mark at klomp dot org
` (13 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: wcohen at redhat dot com @ 2020-09-30 18:22 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
--- Comment #4 from William Cohen <wcohen at redhat dot com> ---
This experiment was using abidiff built from the upstream libabigail repo
commit 59610d5572bf8a997b0f490cae20d42f73acf3e1
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (3 preceding siblings ...)
2020-09-30 18:22 ` wcohen at redhat dot com
@ 2020-10-01 16:01 ` mark at klomp dot org
2020-10-01 17:00 ` wcohen at redhat dot com
` (12 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: mark at klomp dot org @ 2020-10-01 16:01 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
Mark Wielaard <mark at klomp dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mark at klomp dot org
--- Comment #5 from Mark Wielaard <mark at klomp dot org> ---
Attachment #2 "the -g -O2 debuginfo" refers to
libpfm-4.11.1-1.fc32_gcc_o2__g_.x86_64 as alt file. Could you also attach that
one? That will make analyzing the difference slightly easier.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (4 preceding siblings ...)
2020-10-01 16:01 ` mark at klomp dot org
@ 2020-10-01 17:00 ` wcohen at redhat dot com
2020-10-01 20:50 ` mark at klomp dot org
` (11 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: wcohen at redhat dot com @ 2020-10-01 17:00 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
William Cohen <wcohen at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #12872|0 |1
is obsolete| |
Attachment #12873|0 |1
is obsolete| |
Attachment #12874|0 |1
is obsolete| |
Attachment #12875|0 |1
is obsolete| |
--- Comment #6 from William Cohen <wcohen at redhat dot com> ---
Created attachment 12882
--> https://sourceware.org/bugzilla/attachment.cgi?id=12882&action=edit
Files to reproduce the problem
Steps to reproduce the problem from the tarball file.
tar xvz bz26684.tar.gz
cd bz26684
abidiff g/libpfm.so.4.11.1 dwarf5/libpfm.so.4.11.1
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (5 preceding siblings ...)
2020-10-01 17:00 ` wcohen at redhat dot com
@ 2020-10-01 20:50 ` mark at klomp dot org
2020-10-01 20:54 ` mark at klomp dot org
` (10 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: mark at klomp dot org @ 2020-10-01 20:50 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
--- Comment #7 from Mark Wielaard <mark at klomp dot org> ---
There are a couple of issues in the libabigail code.
It has some code for die_unsigned_constant_attribute which relies on specific
FORMs which doesn't handle DW_FORM_implicit_const (and technically
DW_FORM_implicit_const represents a signed value). Ideally libabigail shouldn't
have to deal with forms directly but should be able to rely on the dwarf_attr
functions in libdw to get attribute values so it doesn't have to deal with any
particular data representation. In particular handling of
DW_AT_byte_size and DW_AT_bit_size should probably simply use and dwarf_attr
plus dwarf_formudata.
Secondly in libabigail only handles DW_AT_data_member_location, but not
DW_AT_data_bit_offset. Technically DW_AT_data_bit_offset is already in DWARF4,
but gcc only outputs it for DWARF5 (from gcc/dwarf2out.c):
/* While DW_AT_data_bit_offset has been added already in DWARF4,
e.g. GDB only added support to it in November 2016. For DWARF5
we need newer debug info consumers anyway. We might change this
to dwarf_version >= 4 once most consumers catched up. */
Note that if there is a DW_AT_data_bit_offset instead of a
DW_AT_data_member_location then there will be no DW_AT_byte_size and no
DW_AT_bit_offset.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (6 preceding siblings ...)
2020-10-01 20:50 ` mark at klomp dot org
@ 2020-10-01 20:54 ` mark at klomp dot org
2020-10-01 21:55 ` mark at klomp dot org
` (9 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: mark at klomp dot org @ 2020-10-01 20:54 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
--- Comment #8 from Mark Wielaard <mark at klomp dot org> ---
Simpler example that shows the issue:
struct pea
{
int type;
long a:1, b:1, c:1;
};
struct pea p;
gcc -gdwarf-4:
[ 1d] structure_type abbrev: 2
name (string) "pea"
byte_size (data1) 8
decl_file (data1) bf.c (1)
decl_line (data1) 1
decl_column (data1) 8
sibling (ref4) [ 62]
[ 2a] member abbrev: 3
name (strp) "type"
decl_file (data1) bf.c (1)
decl_line (data1) 3
decl_column (data1) 7
type (ref4) [ 62]
data_member_location (data1) 0
[ 37] member abbrev: 4
name (string) "a"
decl_file (data1) bf.c (1)
decl_line (data1) 4
decl_column (data1) 8
type (ref4) [ 69]
byte_size (data1) 8
bit_size (data1) 1
bit_offset (data1) 31
data_member_location (data1) 0
[ 45] member abbrev: 4
name (string) "b"
decl_file (data1) bf.c (1)
decl_line (data1) 4
decl_column (data1) 13
type (ref4) [ 69]
byte_size (data1) 8
bit_size (data1) 1
bit_offset (data1) 30
data_member_location (data1) 0
[ 53] member abbrev: 4
name (string) "c"
decl_file (data1) bf.c (1)
decl_line (data1) 4
decl_column (data1) 18
type (ref4) [ 69]
byte_size (data1) 8
bit_size (data1) 1
bit_offset (data1) 29
data_member_location (data1) 0
gcc -gdwarf-5:
[ 1e] structure_type abbrev: 3
name (string) "pea"
byte_size (data1) 8
decl_file (data1) bf.c (1)
decl_line (data1) 1
decl_column (data1) 8
sibling (ref4) [ 54]
[ 2b] member abbrev: 4
name (strp) "type"
decl_file (data1) bf.c (1)
decl_line (data1) 3
decl_column (data1) 7
type (ref4) [ 54]
data_member_location (data1) 0
[ 38] member abbrev: 1
name (string) "a"
decl_file (implicit_const) bf.c (1)
decl_line (implicit_const) 4
decl_column (data1) 8
type (ref4) [ 5b]
bit_size (implicit_const) 1
data_bit_offset (data1) 32
[ 41] member abbrev: 1
name (string) "b"
decl_file (implicit_const) bf.c (1)
decl_line (implicit_const) 4
decl_column (data1) 13
type (ref4) [ 5b]
bit_size (implicit_const) 1
data_bit_offset (data1) 33
[ 4a] member abbrev: 1
name (string) "c"
decl_file (implicit_const) bf.c (1)
decl_line (implicit_const) 4
decl_column (data1) 18
type (ref4) [ 5b]
bit_size (implicit_const) 1
data_bit_offset (data1) 34
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (7 preceding siblings ...)
2020-10-01 20:54 ` mark at klomp dot org
@ 2020-10-01 21:55 ` mark at klomp dot org
2020-10-02 10:07 ` dodji at redhat dot com
` (8 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: mark at klomp dot org @ 2020-10-01 21:55 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
--- Comment #9 from Mark Wielaard <mark at klomp dot org> ---
P.S. Note that the actual bit offset for the different attributes is defined
differently:
DW_AT_bit_offset: The bit offset attribute describes the offset in bits of the
high order bit of a value of the given type from the high order bit of the
storage unit used to contain that value.
DW_AT_data_bit_offset: the value is an integer constant that specifies the
number of bits from the beginning of the containing entity to the beginning of
the data member.
DWARF5 has some example for big and little endian in D.2.8 C/C++ Bit-Field
Examples
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (8 preceding siblings ...)
2020-10-01 21:55 ` mark at klomp dot org
@ 2020-10-02 10:07 ` dodji at redhat dot com
2020-10-02 14:42 ` mark at klomp dot org
` (7 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: dodji at redhat dot com @ 2020-10-02 10:07 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
dodji at redhat dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (9 preceding siblings ...)
2020-10-02 10:07 ` dodji at redhat dot com
@ 2020-10-02 14:42 ` mark at klomp dot org
2020-10-02 14:46 ` mark at klomp dot org
` (6 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: mark at klomp dot org @ 2020-10-02 14:42 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
--- Comment #10 from Mark Wielaard <mark at klomp dot org> ---
Created attachment 12885
--> https://sourceware.org/bugzilla/attachment.cgi?id=12885&action=edit
subrange_type bounds signedness is given by underlying type
I was wrong about this:
> It has some code for die_unsigned_constant_attribute which relies on
> specific FORMs which doesn't handle DW_FORM_implicit_const (and technically
> DW_FORM_implicit_const represents a signed value). Ideally libabigail
> shouldn't have to deal with forms directly but should be able to rely on the
> dwarf_attr functions in libdw to get attribute values so it doesn't have to
> deal with any particular data representation. In particular handling of
> DW_AT_byte_size and DW_AT_bit_size should probably simply use and dwarf_attr
> plus dwarf_formudata.
It turns out the code that directly inspects the DW_FORMs and (signedness) is
only used by the build_subrange_type code to properly initialize the
bound_values. I believe that code is actually wrong. The signedness of the
bound_values isn't determined by the specific form used, but by the signedness
of the underlying type (if it has one). The attached patch determines the
signedness by looking at the underlying type and removes the code that directly
checks specific forms.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (10 preceding siblings ...)
2020-10-02 14:42 ` mark at klomp dot org
@ 2020-10-02 14:46 ` mark at klomp dot org
2020-10-02 14:52 ` mark at klomp dot org
` (5 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: mark at klomp dot org @ 2020-10-02 14:46 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
--- Comment #11 from Mark Wielaard <mark at klomp dot org> ---
The actual change from DW_AT_data_member_location plus DW_AT_bit_offset to
DW_AT_data_bit_offset is harder than it looks because the representation of the
offset changes for little endian systems. And arguably currently libabigail
handles DW_AT_bit_offset incorrect for little endian systems... tricky.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (11 preceding siblings ...)
2020-10-02 14:46 ` mark at klomp dot org
@ 2020-10-02 14:52 ` mark at klomp dot org
2020-10-20 10:26 ` dodji at redhat dot com
` (4 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: mark at klomp dot org @ 2020-10-02 14:52 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
--- Comment #12 from Mark Wielaard <mark at klomp dot org> ---
Another random observation, the handling of strings by interpreting the DW_FORM
is also a little ewww IMHO. Note that at some point dwz in DWAR5 mode will
generate DW_FORM_strp_sup instead of DW_FORM_GNU_strp_alt.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (12 preceding siblings ...)
2020-10-02 14:52 ` mark at klomp dot org
@ 2020-10-20 10:26 ` dodji at redhat dot com
2020-10-23 8:24 ` dodji at redhat dot com
` (3 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: dodji at redhat dot com @ 2020-10-20 10:26 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
--- Comment #13 from dodji at redhat dot com ---
I have put together a patch to support the DW_AT_data_bit_offset attribute and
also to interpret the DW_AT_bit_offset attribute correctly on little endian
machines.
It's available at
https://sourceware.org/git/?p=libabigail.git;a=commit;h=4e9bfc1212c017cc18f0044b76c37ca3be9ba625,
in the PR26684 branch which can be browsed at
https://sourceware.org/git/?p=libabigail.git;a=shortlog;h=refs/heads/PR26684.
With this patch libabigail should be able to compare two binaries resulting
from the same program, one being compiled with DWARF4 and the other one with
DWARF5. The result of the comparison should yield the empty set.
The problem now is that abixml files emitted using a previous version of
Libabigail that was doing the wrong interpretation of DW_AT_bit_offset will now
be incompatible with abixml files emitted with this patch.
So, I am thinking about introducing a new abixml version (2.0?) which would be
incompatible with the current 1.0 one. That way, I can add code to prevent
comparing 1.0 abixml versions against 2.0 ones, as well as comparing 1.0 abixml
files against binaries loaded with the new code. I'll be working on that now.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (13 preceding siblings ...)
2020-10-20 10:26 ` dodji at redhat dot com
@ 2020-10-23 8:24 ` dodji at redhat dot com
2020-10-23 10:35 ` fche at redhat dot com
` (2 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: dodji at redhat dot com @ 2020-10-23 8:24 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
--- Comment #14 from dodji at redhat dot com ---
The PR26684 branch now has a patch which bumps the version number of the ABIXML
format to "2.0", which is incompatible with the current "1.0" format.
The patch also modifies abidiff to make it avoid comparing input files with
incompatible version numbers. So abidiff will now refuse to compare an ABIXML
file which has the "1.0" format against a corpus originating from analyzing a
binary using the fixed interpretation of DW_AT_bit_offset. Users will have to
re-generate their ABIXML files using a current abidw, if they want to use this
version of libabigail.
Of course, this is not yet merged into master.
I welcome your feebacks on this approach, as always.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (14 preceding siblings ...)
2020-10-23 8:24 ` dodji at redhat dot com
@ 2020-10-23 10:35 ` fche at redhat dot com
2020-10-23 11:29 ` dodji at redhat dot com
2023-01-01 18:09 ` dodji at redhat dot com
17 siblings, 0 replies; 19+ messages in thread
From: fche at redhat dot com @ 2020-10-23 10:35 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
Frank Ch. Eigler <fche at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fche at redhat dot com
--- Comment #15 from Frank Ch. Eigler <fche at redhat dot com> ---
Just some vague opinion from the backward compatibility peanut galary:
Was the misinterpretation ambiguous / information-losing? If not, then it does
not seem necessary to do a major flag-day version bump, because abidiff could
read a v1 xml file, convert from its buggy bit numbering scheme to the correct
one. It could treat the data (or even rewrite it) as though it were a v2
correct one. Heck, if the buggy data is straightforward to correct in xml,
could put the correct bit# into a new-name xml element/attribute nearby, rather
than requiring a top level version bump?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (15 preceding siblings ...)
2020-10-23 10:35 ` fche at redhat dot com
@ 2020-10-23 11:29 ` dodji at redhat dot com
2023-01-01 18:09 ` dodji at redhat dot com
17 siblings, 0 replies; 19+ messages in thread
From: dodji at redhat dot com @ 2020-10-23 11:29 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
--- Comment #16 from dodji at redhat dot com ---
"fche at redhat dot com" <sourceware-bugzilla@sourceware.org> writes:
> --- Comment #15 from Frank Ch. Eigler <fche at redhat dot com> ---
Thank you Frank for taking the time to reply to this!
> Just some vague opinion from the backward compatibility peanut galary:
>
> Was the misinterpretation ambiguous / information-losing?
Sadly, I am afraid it was :-( (unless I am missing something).
For little endian machines, libabigail was wrongly interpreting
DW_AT_bit_offset as being the same value as for big endian machines. So
the resulting data member offset we were getting is wrong. And that
wrong number is what's saved in the abixml file.
At the abixml level, we don't save the other low level details of the
bitfield layout that would help us convert that buggy data member offset
into the correct one. We just save the offset of the data member and
its type. Now in hindsight, I am thinking maybe I should have save some
of that information ...
> If not, then it does not seem necessary to do a major flag-day version
> bump, because abidiff could read a v1 xml file, convert from its buggy
> bit numbering scheme to the correct one. It could treat the data (or
> even rewrite it) as though it were a v2 correct one.
> Heck, if the buggy data is straightforward to correct in xml, could
> put the correct bit# into a new-name xml element/attribute nearby,
> rather than requiring a top level version bump?
Yes, it would have been super cool to be able to do that ...
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
2020-09-30 18:18 [Bug default/26684] New: abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo wcohen at redhat dot com
` (16 preceding siblings ...)
2020-10-23 11:29 ` dodji at redhat dot com
@ 2023-01-01 18:09 ` dodji at redhat dot com
17 siblings, 0 replies; 19+ messages in thread
From: dodji at redhat dot com @ 2023-01-01 18:09 UTC (permalink / raw)
To: libabigail
https://sourceware.org/bugzilla/show_bug.cgi?id=26684
dodji at redhat dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #17 from dodji at redhat dot com ---
The support for this has been merged in into the main branch and released in
libabigail 2.0 a long ago.
I am thus closing this bug.
Thanks.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 19+ messages in thread