public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Giuliano Procida <gprocida@google.com>, libabigail@sourceware.org
Cc: dodji@seketeli.org, kernel-team@android.com, maennich@google.com
Subject: Re: [PATCH 0/1] Fix interpretation of ARM32 CFI
Date: Tue, 11 Jan 2022 18:46:55 +0100	[thread overview]
Message-ID: <62f9bc953a1f3e0be09e98f2455411afc30399b8.camel@klomp.org> (raw)
In-Reply-To: <20220111163412.3012602-1-gprocida@google.com>

Hi Giuliano,

On Tue, 2022-01-11 at 16:34 +0000, Giuliano Procida wrote:
> This patch ensures correct symbol address for ARM32 shared libraries
> that have been complied with CFI.
> 
> I have no idea what the implications are for PPC64. It's also
> possible
> the fix-up code would better belong in some kind of helper.
> 
> Feedback welcome as always!

I am not familiar enough with the libabigail code to say this is the
correct place/way to do these fixups. But the need for fixups
themselves seem correct.

For ARM32 bit zero encodes whether an function address is THUMB or ARM,
so to get the "real" function address you have to mask bit zero.

For PPC64 (and ppc32 btw) a function symbol value will point to the
function descriptor (OPD entry) (except for .symbols) the function
descriptor will point to the actual symbol address.

elfutils has a somewhat complicated function that tries to provide you
the actual symbol value and the associated address for that symbol. But
I don't think that fits in the code here:

/* Fetch one entry from the module's symbol table and the associated
   address value.  On errors, returns NULL.  If successful, fills in
   *SYM, *ADDR and returns the string for st_name.  This works like
   gelf_getsym.  *ADDR is set to the st_value adjusted to an absolute
   value based on the module's location, when the symbol is in an
   SHF_ALLOC section.  For non-ET_REL files, if the arch uses function
   descriptors, and the st_value points to one, *ADDR will be resolved
   to the actual function entry address.  The SYM->ST_VALUE itself
   isn't adjusted in any way.  Fills in ELFP, if not NULL, with the
   ELF file the symbol originally came from.  Note that symbols can
   come from either the main, debug or auxiliary ELF symbol file
   (either dynsym or symtab).  If SHNDXP is non-null, it's set with
   the section index (whether from st_shndx or extended index table);
   in case of a symbol in a non-allocated section, *SHNDXP is instead
   set to -1.  Fills in BIAS, if not NULL, with the difference between
   addresses within the loaded module and those in symbol table of the
   ELF file.  Note that the address associated with the symbol might
   be in a different section than the returned symbol.  The section in
   the main elf file in which returned ADDR falls can be found with
   dwfl_module_address_section.  */
extern const char *dwfl_module_getsym_info (Dwfl_Module *mod, int ndx,
                                            GElf_Sym *sym, GElf_Addr *addr,
                                            GElf_Word *shndxp,
                                            Elf **elfp, Dwarf_Addr *bias)
  __nonnull_attribute__ (3, 4);

Cheers,

Mark

      parent reply	other threads:[~2022-01-11 17:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11 16:34 Giuliano Procida
2022-01-11 16:34 ` [PATCH 1/1] symtab reader: fix up alternative addresses Giuliano Procida
2022-01-11 17:46 ` Mark Wielaard [this message]

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=62f9bc953a1f3e0be09e98f2455411afc30399b8.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=dodji@seketeli.org \
    --cc=gprocida@google.com \
    --cc=kernel-team@android.com \
    --cc=libabigail@sourceware.org \
    --cc=maennich@google.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).