From: Mark Wielaard <email@example.com>
To: Tom de Vries <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com
Subject: Re: [PATCH][testsuite] Handle readelf following links by default
Date: Sun, 28 Feb 2021 16:21:34 +0100 [thread overview]
Message-ID: <20210228152134.GH3014@wildebeest.org> (raw)
Added Nick to the CC since he seems to have introduced this new
On Sun, Feb 28, 2021 at 08:36:49AM +0100, Tom de Vries wrote:
> Since binutils commit c46b706620e "Change the readelf and objdump programs so
> that they will automatically follow links to separate debug info files." there
> are a few FAILs in the dwz testsuite.
> In the case of gnu-debugaltlink-name.sh, I think this is caused by a binutils
> bug, filed as PR27478.
> In the case of odr-struct-multifile.sh, this is just due to flipping the
> Fix/workaround this by testing whether the new -Wn readelf flag is supported,
> and if so, adding it to the readelf call.
> Any comments?
I think this is an odd bug in binutils. --debug-dump=follow-links
seems to confuses two separate concepts. First whether or not to show
data that might be stored in a "linked" file. Like whether to show a
DW_FORM_GNU_alt_strp value. This seems fine and should indeed be done
by default (that is also what eu-readelf does).
Second whether to dump whole sections from the linked files. That is
IMHO something completely different and causes the bug you filed. This
second use should not be the default. And probably should be called
something different, maybe --debug-dump=dump-links.
Since this is luckily not yet in any released binutils lets fix this
in binutils instead of trying to work around it in dwz. I am pretty
sure it will break various other testsuites that rely on binutils
readelf --debug-dump output if it suddenly also dumped sections from
other files by default.
next prev parent reply other threads:[~2021-02-28 15:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-28 7:36 Tom de Vries
2021-02-28 15:21 ` Mark Wielaard [this message]
2021-03-01 12:50 ` Mark Wielaard
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).