From: Giuliano Procida <gprocida@google.com>
To: Mark Wielaard <mark@klomp.org>
Cc: "Dodji Seketeli" <dodji@seketeli.org>,
libabigail@sourceware.org,
"Matthias Männich" <maennich@google.com>
Subject: Re: [PATCH] symtab-reader: Setup aliases before checking ppc64 opd function entries
Date: Tue, 17 May 2022 14:51:44 +0100 [thread overview]
Message-ID: <CAGvU0H=Jesd6AC+Avkjv4g_o7Kmc=t5ZV6VrRc94WqcMaBEFSw@mail.gmail.com> (raw)
In-Reply-To: <aecc7208ed5d4656f56d38b17b0899bee86321a7.camel@klomp.org>
Hi.
On Tue, 17 May 2022 at 10:59, Mark Wielaard <mark@klomp.org> wrote:
>
> Hi Dodji,
>
> On Mon, 2022-05-16 at 11:43 +0200, Dodji Seketeli wrote:
> > I have thus adjusted your patch to keep its spirit while making it
> > apply to the current code base.
> >
> > Giuliano, Mark, would you guys please review the patch, when you have
> > time, and tell me what you think?
>
> It looks good to me, some small comments below. I don't have access to
> a ppc64[be] setup anymore, but the buildbot has:
> https://builder.sourceware.org/buildbot/#/builders/libabigail-debian-ppc64
> So hopefully after this patch that will turn green.
>
I have some minor comments. Other than that, it looks good to me.
I'm CCing Matthias as he did a lot of the reworking into the current
structure, I think.
> > From 768d13cb21a0d6c8ebd8ed0530a095a036c4c9b5 Mon Sep 17 00:00:00 2001
> > From: Mark Wielaard <mark@klomp.org>
> > Date: Mon, 16 May 2022 10:53:55 +0200
> > Subject: [PATCH] symtab-reader: Setup aliases before checking ppc64 opd function entries
> >
> > The update_function_entry_address_symbol_map function checks whether
> > the given symbol is an alias of another symbol or a special ppc64
> > ELFv1 function entry symbol. This requires the symbol aliases to
> > already been setup. But the alias entries were only setup after
> > calling update_function_entry_address_symbol_map. Make sure that
> > the symbol aliases have been setup and only then call the special
> > ppc64 update_function_entry_address_symbol_map function. But make
> > sure the arm32 function symbol entry address cleanup is done before
> > checking for aliases.
> >
> > This patch renames symtab::get_symbol_value into
> > symtab::setup_symbol_lookup_tables to better reflect what it does.
> >
> > It is in that function that the call to
> > update_function_entry_address_symbol_map is performed, the arm32 symbol address
> > cleanup is done and the ppc64 ELFv1 function address plumbing
> > is done.
>
> Is that second line too long?
>
> > So arranging for update_function_entry_address_symbol_map to be called
> > after symbol aliases are setup for ppc64 is also done in that
> > function. That way, symtab::load_ only have to call
> > symtab::setup_symbol_lookup_tables to have aliases setup.
>
> Same for the first line here.
>
> > This fixes runtestslowselfcompare.sh on ppc64 (ELFv1) with
> > ENABLE_SLOW_TEST=yes
> >
> > * src/abg-symtab-reader.cc
> > (symtab::setup_symbol_lookup_tables): Rename
> > symtab::get_symbol_value into this. Setup symbol aliases before
> > setting up function entry address maps for ppc64 ELFv1 and after
> > fixing up arm32/64 addresses.
> > (symtab::load_): Invoke the new setup_symbol_lookup_tables.
> > update_function_entry_address_symbol_map after setting up aliases.
> > No need to setup symbol aliases anymore.
> > (symtab::add_alternative_address_lookups): Invoke the new
> > setup_symbol_lookup_tables.
> >
> > Signed-off-by: Mark Wielaard <mark@klomp.org>
> > Signed-off-by: Dodji Seketeli <dodji@redhat.com>
> > ---
> > src/abg-symtab-reader.cc | 58 +++++++++++++++++++++-------------------
> > src/abg-symtab-reader.h | 6 ++---
> > 2 files changed, 33 insertions(+), 31 deletions(-)
> >
> > diff --git a/src/abg-symtab-reader.cc b/src/abg-symtab-reader.cc
> > index 3740cb7a..05be4d6b 100644
> > --- a/src/abg-symtab-reader.cc
> > +++ b/src/abg-symtab-reader.cc
> > @@ -343,17 +343,7 @@ symtab::load_(Elf* elf_handle,
> > }
> > }
> > else if (symbol_sptr->is_defined())
> > - {
> > - const GElf_Addr symbol_value =
> > - get_symbol_value(elf_handle, sym, symbol_sptr);
> > - const auto result =
> > - addr_symbol_map_.emplace(symbol_value, symbol_sptr);
> > - if (!result.second)
> > - // A symbol with the same address already exists. This
> > - // means this symbol is an alias of the main symbol with
> > - // that address. So let's register this new alias as such.
> > - result.first->second->get_main_symbol()->add_alias(symbol_sptr);
> > - }
> > + setup_symbol_lookup_tables(elf_handle, sym, symbol_sptr);
> > }
> >
> > add_alternative_address_lookups(elf_handle);
> > @@ -468,6 +458,10 @@ symtab::update_main_symbol(GElf_Addr addr, const std::string& name)
> > /// Various adjustments and bookkeeping may be needed to provide a correct
> > /// interpretation (one that matches DWARF addresses) of raw symbol values.
> > ///
> > +/// This is a sub-routine for symtab::load_and
> > +/// symtab::add_alternative_address_lookups and and must be called
and and / and
> > +/// only once during the execution of the former.
I've lost a bit of the context, but where comments say "only once"
should that be "only once per symbol"?
> > +///
> > /// @param elf_handle the ELF handle
> > ///
> > /// @param elf_symbol the ELF symbol
> > @@ -476,9 +470,9 @@ symtab::update_main_symbol(GElf_Addr addr, const std::string& name)
> > ///
> > /// @return a possibly-adjusted symbol value
> > GElf_Addr
> > -symtab::get_symbol_value(Elf* elf_handle,
> > - GElf_Sym* elf_symbol,
> > - const elf_symbol_sptr& symbol_sptr)
> > +symtab::setup_symbol_lookup_tables(Elf* elf_handle,
> > + GElf_Sym* elf_symbol,
> > + const elf_symbol_sptr& symbol_sptr)
> > {
> > const bool is_arm32 = elf_helpers::architecture_is_arm32(elf_handle);
> > const bool is_arm64 = elf_helpers::architecture_is_arm64(elf_handle);
> > @@ -488,23 +482,33 @@ symtab::get_symbol_value(Elf* elf_handle,
> > elf_helpers::maybe_adjust_et_rel_sym_addr_to_abs_addr(elf_handle,
> > elf_symbol);
> >
> > - if (symbol_sptr->is_function())
> > - {
> > - if (is_arm32)
> > - // Clear bit zero of ARM32 addresses as per "ELF for the Arm
> > - // Architecture" section 5.5.3.
> > - // https://static.docs.arm.com/ihi0044/g/aaelf32.pdf
> > - symbol_value &= ~1;
> > - else if (is_ppc64)
> > - update_function_entry_address_symbol_map(elf_handle, elf_symbol,
> > - symbol_sptr);
> > - }
> > + if (symbol_sptr->is_function() && is_arm32)
> > + // Clear bit zero of ARM32 addresses as per "ELF for the Arm
> > + // Architecture" section 5.5.3.
> > + // https://static.docs.arm.com/ihi0044/g/aaelf32.pdf
> > + symbol_value &= ~1;
> > +
> > if (is_arm64)
> > // Copy bit 55 over bits 56 to 63 which may be tag information.
> > symbol_value = symbol_value & (1ULL<<55)
> > ? symbol_value | (0xffULL<<56)
> > : symbol_value &~ (0xffULL<<56);
>
> This part is new. I think it is correct to do this, before setting up
> the aliases, just like we mask off the zero bit for arm32. But it would
> be good if Giuliano could confirm.
>
The two ARM adjustments belong together. I wasn't sure about PPC, so
I'm glad that it's getting moved to the right place.
> > + if (symbol_sptr->is_defined())
> > + {
> > + const auto result =
> > + addr_symbol_map_.emplace(symbol_value, symbol_sptr);
> > + if (!result.second)
> > + // A symbol with the same address already exists. This
> > + // means this symbol is an alias of the main symbol with
> > + // that address. So let's register this new alias as such.
> > + result.first->second->get_main_symbol()->add_alias(symbol_sptr);
> > + }
> > +
> > + if (symbol_sptr->is_function() && is_ppc64)
IIRC, someone said that this should apply to PPC32 as well, perhaps you, Mark?
> > + update_function_entry_address_symbol_map(elf_handle, elf_symbol,
> > + symbol_sptr);
>
> I would add a comment here to say something like:
>
> // Note, update_function_entry_address_symbol_map depends
> // on the symbol aliases been setup.
>
> So it is clear why this needs to be done after the add_alias call
> above.
>
> > return symbol_value;
> > }
> >
> > @@ -656,9 +660,7 @@ symtab::add_alternative_address_lookups(Elf* elf_handle)
> > if (symbols.size() == 1)
> > {
> > const auto& symbol_sptr = symbols[0];
> > - const GElf_Addr symbol_value =
> > - get_symbol_value(elf_handle, sym, symbol_sptr);
> > - addr_symbol_map_.emplace(symbol_value, symbol_sptr);
> > + setup_symbol_lookup_tables(elf_handle, sym, symbol_sptr);
> > }
> > }
> > }
> > diff --git a/src/abg-symtab-reader.h b/src/abg-symtab-reader.h
> > index bddde2f6..948fc270 100644
> > --- a/src/abg-symtab-reader.h
> > +++ b/src/abg-symtab-reader.h
> > @@ -290,9 +290,9 @@ private:
> > string_elf_symbols_map_sptr variables_symbol_map);
> >
> > GElf_Addr
> > - get_symbol_value(Elf* elf_handle,
> > - GElf_Sym* elf_symbol,
> > - const elf_symbol_sptr& symbol_sptr);
> > + setup_symbol_lookup_tables(Elf* elf_handle,
> > + GElf_Sym* elf_symbol,
> > + const elf_symbol_sptr& symbol_sptr);
> >
> > void
> > update_function_entry_address_symbol_map(Elf* elf_handle,
> > --
>
> Looks good.
>
> Thanks,
>
> Mark
Cheers,
Giuliano.
next prev parent reply other threads:[~2022-05-17 13:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 9:43 Dodji Seketeli
2022-05-17 9:59 ` Mark Wielaard
2022-05-17 13:51 ` Giuliano Procida [this message]
2022-05-17 14:03 ` Mark Wielaard
2022-05-27 16:33 ` Dodji Seketeli
2022-05-27 23:05 ` Mark Wielaard
2022-05-30 8:44 ` Dodji Seketeli
-- strict thread matches above, loose matches on Subject: below --
2022-05-01 22:16 Mark Wielaard
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='CAGvU0H=Jesd6AC+Avkjv4g_o7Kmc=t5ZV6VrRc94WqcMaBEFSw@mail.gmail.com' \
--to=gprocida@google.com \
--cc=dodji@seketeli.org \
--cc=libabigail@sourceware.org \
--cc=maennich@google.com \
--cc=mark@klomp.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).