From: Mark Wielaard <mark@klomp.org>
To: Ben Woodard <woodard@redhat.com>
Cc: Ben Woodard via Libabigail <libabigail@sourceware.org>
Subject: Re: Fwd: Testing Setup - More Tests and Automation?
Date: Sat, 30 Apr 2022 00:02:31 +0200 [thread overview]
Message-ID: <20220429220231.GD7305@gnu.wildebeest.org> (raw)
In-Reply-To: <20220429211304.GC7305@gnu.wildebeest.org>
Hi,
On Fri, Apr 29, 2022 at 11:13:04PM +0200, Mark Wielaard wrote:
> And it caught an issue on fedora-ppc64 and debian-ppc64
> https://builder.sourceware.org/buildbot/#/builders/libabigail-fedora-ppc64
> https://builder.sourceware.org/buildbot/#/builders/libabigail-debian-ppc64
>
> FAIL: runtestslowselfcompare.sh
> ===============================
> + abidw=../tools/abidw
> + objdir=../src/.libs
> + echo ENABLE_SLOW_TEST=yes
> ENABLE_SLOW_TEST=yes
> + test xyes '!=' x
> ++ ../tools/abidw --abidiff ../src/.libs/libabigail.so
> lt-abidw: abg-symtab-reader.cc:557: void abigail::symtab_reader::symtab::update_function_entry_address_symbol_map(Elf*, GElf_Sym*, const elf_symbol_sptr&): Assertion `__abg_cond__' failed.
> FAIL runtestslowselfcompare.sh (exit status: 134)
>
> It didn't fail any other builder (so it isn't power specific, because
> fedora-ppc64le is green, and it isn't big endian specific, because
> fedora-s390x is green).
>
> But it might have to do with ppc64 function descriptors, which are
> ppc64 specific.
It indeed is. The issue is in update_function_entry_address_symbol_map
which is only called for ppc64 ELFv1 binaries.
src/.libs/libabigail.so contains two identical symbols:
468: 0000000000427498 604 FUNC GLOBAL DEFAULT 21 _ZN7abigail10comparison12pointer_diffC2ESt10shared_ptrINS_2ir16pointer_type_defEES5_S2_INS0_4diffEES2_INS0_12diff_contextEE
7362: 0000000000427498 604 FUNC GLOBAL DEFAULT 21 _ZN7abigail10comparison12pointer_diffC2ESt10shared_ptrINS_2ir16pointer_type_defEES5_S2_INS0_4diffEES2_INS0_12diff_contextEE
But those are not seen as aliases. And the assert says:
ABG_ASSERT(two_symbols_alias
|| symbol_is_foo_and_prev_symbol_is_dot_foo);
I don't understand the aliasing code well enough to understand why
yet.
Cheers,
Mark
next prev parent reply other threads:[~2022-04-29 22:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAM=pu++-JdBdizXQ9dj8eUypXg7fpPOTDzN6BL1NY-TFvk++kQ@mail.gmail.com>
2022-04-28 0:55 ` Ben Woodard
2022-04-28 1:57 ` v
2022-04-30 19:55 ` Mark Wielaard
2022-04-30 20:36 ` v
2022-04-30 21:48 ` Mark Wielaard
2022-04-30 22:38 ` v
2022-05-01 22:42 ` Mark Wielaard
2022-05-01 22:46 ` v
2022-06-09 11:31 ` Thinking different (was Re: Testing Setup - More Tests and Automation?) Dodji Seketeli
2022-06-09 19:48 ` v
2022-06-15 14:21 ` Dodji Seketeli
2022-06-09 11:18 ` Testing Setup - More Tests and Automation? Dodji Seketeli
2022-06-09 11:11 ` Dodji Seketeli
2022-06-14 10:05 ` Mark Wielaard
2022-04-28 8:06 ` Fwd: " Mark Wielaard
2022-04-29 21:13 ` Mark Wielaard
2022-04-29 22:02 ` Mark Wielaard [this message]
2022-05-03 19:08 ` Ben Woodard
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=20220429220231.GD7305@gnu.wildebeest.org \
--to=mark@klomp.org \
--cc=libabigail@sourceware.org \
--cc=woodard@redhat.com \
/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).