[all-commits] [llvm/llvm-project] 15b7b3: [libomptarget] Support BE ELF files in plugins-nex...

[Ulrich Weigand via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 15b7b3182cc28f4f0b950bd73d931caa27b833ec
      https://github.com/llvm/llvm-project/commit/15b7b3182cc28f4f0b950bd73d931caa27b833ec
  Author: Ulrich Weigand <ulrich.weigand at de.ibm.com>
  Date:   2024-03-06 (Wed, 06 Mar 2024)

  Changed paths:
    M openmp/libomptarget/plugins-nextgen/common/include/GlobalHandler.h
    M openmp/libomptarget/plugins-nextgen/common/include/Utils/ELF.h
    M openmp/libomptarget/plugins-nextgen/common/src/GlobalHandler.cpp
    M openmp/libomptarget/plugins-nextgen/common/src/Utils/ELF.cpp

  Log Message:
  -----------
  [libomptarget] Support BE ELF files in plugins-nextgen (#83976)

Code in plugins-nextgen reading ELF files is currently hard-coded to
assume a 64-bit little-endian ELF format. Unfortunately, this assumption
is even embedded in the interface between GlobalHandler and Utils/ELF
routines, which use ELF64LE types.

To fix this, I've refactored the interface to push all ELF specific
types into Utils/ELF. Specifically, this patch removes both the
getSymbol and getSymbolAddress routines and replaces them with a
single findSymbolInImage, which gets a StringRef identifying the
raw object file image as input, and returns a StringRef covering
the data addressed by the symbol (address and size) if found, or
std::nullopt otherwise.

This allows properly templating over multiple ELF format variants inside
Utils/ELF; specifically, this patch adds support for 64-bit big-endian
ELF files in addition to 64-bit little-endian files.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications