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
prev 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).