mbox series

[0/1] Fix interpretation of ARM32 CFI

Message ID 20220111163412.3012602-1-gprocida@google.com
Headers
Series Fix interpretation of ARM32 CFI |

Message

Giuliano Procida Jan. 11, 2022, 4:34 p.m. UTC 
  Hi.

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!

Regards,
Giuliano.

Giuliano Procida (1):
  symtab reader: fix up alternative addresses

 src/abg-symtab-reader.cc | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

Comments

Mark Wielaard Jan. 11, 2022, 5:46 p.m. UTC | #1 
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