Message ID | 20220111163412.3012602-1-gprocida@google.com |
---|---|
Headers |
Return-Path: <libabigail-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 74F4538A940B for <patchwork@sourceware.org>; Tue, 11 Jan 2022 16:34:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 74F4538A940B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1641918864; bh=J/mX7uDC+OkJ5EvkzQDyBxc6jHOu4MLsmeYQ5FLlfNw=; h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Help: List-Subscribe:From:Reply-To:Cc:From; b=EAi+6d+ladbcdWjMG71NqMLxvogR4FlT0S9AtsvrjS/LXAYKW3N7LuiMOPsh4gQ1k WHZ77EACPcNxAvWdX0V1TQC4ZgPVYXSP2KhQKUCqptORdH4T1f9oh8ERhgOcQ/6bHa eWqIpikRpR+hqoK73vU3Lxbru6hP6lfgJlOQelG4= X-Original-To: libabigail@sourceware.org Delivered-To: libabigail@sourceware.org Received: from mail-ed1-x54a.google.com (mail-ed1-x54a.google.com [IPv6:2a00:1450:4864:20::54a]) by sourceware.org (Postfix) with ESMTPS id 2026B3858D39 for <libabigail@sourceware.org>; Tue, 11 Jan 2022 16:34:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2026B3858D39 Received: by mail-ed1-x54a.google.com with SMTP id j10-20020a05640211ca00b003ff0e234fdfso1161792edw.0 for <libabigail@sourceware.org>; Tue, 11 Jan 2022 08:34:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=J/mX7uDC+OkJ5EvkzQDyBxc6jHOu4MLsmeYQ5FLlfNw=; b=4HoNoi2W7p8+NAm1a7OhiXPvtWhvAveW9BTNuQgvr3T1T6NrTaP8gd0gxEx+oj4jnh K6WDVERtiB4xgFLD2V3f32GQfXpe1/ExURHVGv8412FCxAUZKYtRI265myXg7KEYm3fv SNDCnsz0Sf01kagiB/QRaEvC/kBX/CxB9YS/H+qhwzWpwWyLQzUe30WM2LQFQlHpXP7E 7aVqTRfw9oQK0/42iXc9lDwH7EBTJmn4jSEngZ4WiYWfuANnJdOpZJl6HVTHASh1RiIh iGAtxpn0wP35mI6YUyb95n+0bX8wSQdbVN+R+Gvnp++aGNuc0TsaMAGHu3ceVDHuTvDa CyRA== X-Gm-Message-State: AOAM532OR6V8pG/f+ZBVE5cKW2DK4Amt8U9kGskxwEjUQ9i15YjrOoOe UtftZ6v01VTy6blBJYktKKoG9rZjjg1MlS2/hI2G/OeHE5Noob7WpNphnbnGyqAn3nY/ZolV5cJ S1xe8QFJpsMMFZkM+7iOUVMmQ9toycr0wY8EIgakl8lsLzt5iJT/NmJUTqXuzWAGLLkQDaJI= X-Google-Smtp-Source: ABdhPJziSFlr8KikMUFX8SLR5n7FPnRe0P1AFt7FW6DB11QuGALrV4CjnfERWEdcdddu87ScWzm0UEhpGhWXyg== X-Received: from tef.lon.corp.google.com ([2a00:79e0:d:210:b411:ac04:5f30:7e4e]) (user=gprocida job=sendgmr) by 2002:a17:906:d78a:: with SMTP id pj10mr4390722ejb.72.1641918858753; Tue, 11 Jan 2022 08:34:18 -0800 (PST) Date: Tue, 11 Jan 2022 16:34:11 +0000 Message-Id: <20220111163412.3012602-1-gprocida@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.34.1.575.g55b058a8bb-goog Subject: [PATCH 0/1] Fix interpretation of ARM32 CFI To: libabigail@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-15.3 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project <libabigail.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libabigail>, <mailto:libabigail-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libabigail/> List-Help: <mailto:libabigail-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libabigail>, <mailto:libabigail-request@sourceware.org?subject=subscribe> From: Giuliano Procida via Libabigail <libabigail@sourceware.org> Reply-To: Giuliano Procida <gprocida@google.com> Cc: maennich@google.com, kernel-team@android.com, mark@klomp.org Errors-To: libabigail-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libabigail" <libabigail-bounces+patchwork=sourceware.org@sourceware.org> |
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
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