* [PATCH 1/1] symtab reader: fix up alternative addresses
2022-01-11 16:34 [PATCH 0/1] Fix interpretation of ARM32 CFI Giuliano Procida
@ 2022-01-11 16:34 ` Giuliano Procida
2022-01-11 17:46 ` [PATCH 0/1] Fix interpretation of ARM32 CFI Mark Wielaard
1 sibling, 0 replies; 3+ messages in thread
From: Giuliano Procida @ 2022-01-11 16:34 UTC (permalink / raw)
To: libabigail; +Cc: dodji, kernel-team, gprocida, maennich, mark
CFI symbols need special interpretation and this work is performed by
the add_alternative_address_lookups method.
Some symbol addresses need to be "tweaked" to be correctly interpreted
and this must also happen in add_alternative_address_lookups.
In particular, this commit fixes ARM32 CFI symbol interpretation.
* src/abg-symtab-reader.cc
(symtab::add_alternative_address_lookups): Tweak function
addresses in the same manner as done in symtab::load_.
Signed-off-by: Giuliano Procida <gprocida@google.com>
---
src/abg-symtab-reader.cc | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/src/abg-symtab-reader.cc b/src/abg-symtab-reader.cc
index 0f4d0b65..04e8b23c 100644
--- a/src/abg-symtab-reader.cc
+++ b/src/abg-symtab-reader.cc
@@ -351,6 +351,7 @@ symtab::load_(Elf* elf_handle,
elf_helpers::maybe_adjust_et_rel_sym_addr_to_abs_addr(elf_handle,
sym);
+ // See also symtab::add_alternative_address_lookups.
if (symbol_sptr->is_function())
{
if (is_arm32)
@@ -581,6 +582,9 @@ symtab::update_function_entry_address_symbol_map(
void
symtab::add_alternative_address_lookups(Elf* elf_handle)
{
+ const bool is_arm32 = elf_helpers::architecture_is_arm32(elf_handle);
+ const bool is_ppc64 = elf_helpers::architecture_is_ppc64(elf_handle);
+
Elf_Scn* symtab_section = elf_helpers::find_symtab_section(elf_handle);
if (!symtab_section)
return;
@@ -634,6 +638,19 @@ symtab::add_alternative_address_lookups(Elf* elf_handle)
elf_helpers::maybe_adjust_et_rel_sym_addr_to_abs_addr(
elf_handle, sym);
+ // See also symtab::load_.
+ 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, sym,
+ symbol_sptr);
+ }
+
const auto result =
addr_symbol_map_.emplace(symbol_value, symbol_sptr);
ABG_ASSERT(result.second);
--
2.34.1.575.g55b058a8bb-goog
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH 0/1] Fix interpretation of ARM32 CFI
2022-01-11 16:34 [PATCH 0/1] Fix interpretation of ARM32 CFI 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
1 sibling, 0 replies; 3+ messages in thread
From: Mark Wielaard @ 2022-01-11 17:46 UTC (permalink / raw)
To: Giuliano Procida, libabigail; +Cc: dodji, kernel-team, maennich
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
^ permalink raw reply [flat|nested] 3+ messages in thread