public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: "mark at klomp dot org" <sourceware-bugzilla@sourceware.org>
To: libabigail@sourceware.org
Subject: [Bug default/26684] abidiff says that some bit field elements missing in version of binary with dwarf5 debuginfo.
Date: Fri, 02 Oct 2020 14:42:11 +0000	[thread overview]
Message-ID: <bug-26684-9487-3uDfu7fztU@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-26684-9487@http.sourceware.org/bugzilla/>

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.

  parent reply	other threads:[~2020-10-02 14:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30 18:18 [Bug default/26684] New: " 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
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
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
2020-10-02 14:42 ` mark at klomp dot org [this message]
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
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-26684-9487-3uDfu7fztU@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=libabigail@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).