public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "sourceware at dima dot secretsauce.net" <sourceware-bugzilla@sourceware.org>
To: elfutils-devel@sourceware.org
Subject: [Bug libdw/22546] New: dwarf_aggregate_size() doesn't work for multi-dimensional arrays
Date: Mon, 04 Dec 2017 23:05:00 -0000	[thread overview]
Message-ID: <bug-22546-10460@http.sourceware.org/bugzilla/> (raw)

https://sourceware.org/bugzilla/show_bug.cgi?id=22546

            Bug ID: 22546
           Summary: dwarf_aggregate_size() doesn't work for
                    multi-dimensional arrays
           Product: elfutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libdw
          Assignee: unassigned at sourceware dot org
          Reporter: sourceware at dima dot secretsauce.net
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

Hi. I'm observing that dwarf_aggregate_size() returns bogus results when
looking at double-dimensional arrays. For instance, looking at

  double dd[3][5];

It says the aggregate is 64-bytes long instead of 120. The bug is that it ends
up computing (3+5)*8 instead of 3*5*8.

I'm attaching a simple test case. It loads the current process's debug
information, and prints out the size of dd, defined as above. It shows the
failure:

  dima@fatty:/tmp$ gcc -g -ldw -lelf dwarf_aggregate_size_bug.c -o
dwarf_aggregate_size_bug

  dima@fatty:/tmp$ ./dwarf_aggregate_size_bug                                   
  Found DIE for 'dd'. size: 64

I'm using libelf1 0.168-1 on Debian/sid, although at least version 0.170 has
the bug too.

I'm attaching a proof-of-concept patch to solve this. Note that this patch
isn't final: previously we would compute a separate stride for each dimension,
while the patch only computes the stride once. I don't know what case
specifically that is meant to handle. Tests pass before and after.

If for some reason dwarf_aggregate_size() isn't meant to be used this way, then
it should still be changed to fail in a more obvious way. Answering 64 here is
NEVER the right answer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

             reply	other threads:[~2017-12-04 23:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-04 23:05 sourceware at dima dot secretsauce.net [this message]
2017-12-04 23:06 ` [Bug libdw/22546] " sourceware at dima dot secretsauce.net
2017-12-04 23:18 ` sourceware at dima dot secretsauce.net
2017-12-08  9:47 ` sourceware at dima dot secretsauce.net
2017-12-08  9:49 ` sourceware at dima dot secretsauce.net
2017-12-11 16:31 ` mark at klomp dot org
2017-12-11 22:55 ` mark at klomp dot org
2017-12-12  8:10 ` sourceware at dima dot secretsauce.net
2017-12-12  9:52 ` mark at klomp dot org

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-22546-10460@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=elfutils-devel@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).