From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Q8w/=72=rivosinc.com=gkm@sourceware.org>
Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35])
	by sourceware.org (Postfix) with ESMTPS id 1BD683858D39
	for <binutils@sourceware.org>; Mon,  3 Apr 2023 16:08:10 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1BD683858D39
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com
Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-17786581fe1so31282741fac.10
        for <binutils@sourceware.org>; Mon, 03 Apr 2023 09:08:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=rivosinc-com.20210112.gappssmtp.com; s=20210112; t=1680538089;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=O0YN7zBLKVK7qHPKBJfUje8mxQkmfSCpIrsGR7O9QZ8=;
        b=JbvzC4IN8JytJfvnkmuekJ/Fjg9XCjIoRMqZ5VS/lfVykXNOaS99EXpRTIlXFHDKtw
         uAD0j4nGiSMb0YrD8VAhNai91y3KH2BowXnJRQGA8s0kpbVX57/7Oqu2dXMuiOD1Cvop
         2It7W+QigqvGdgcZYS4MrWboyd8SxVKaTeCPdeFzQHKD+qXNMtM5DzR07ib+cO9o87Nm
         Eu0nFz/qt+0beHUjqssL+XPphEtCcwnpRFJcrAPqsTu9WDQpcIFuUyFQlDCo7kCdR5dT
         3W7ZIxdC6+1auMS9nNphLjCM811I45c5rjgyZO09uYD/aMMvZ8MVJnqL5klff0gB7jaH
         1h8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112; t=1680538089;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=O0YN7zBLKVK7qHPKBJfUje8mxQkmfSCpIrsGR7O9QZ8=;
        b=JNeunSjxZ1erd/dRvsW1Yph7ypkYfiORtKqu+ZihVzp+cNftnv5GZR1Mu9VpBtYvfH
         HwCwoJjKqxfEWODFPX0yvsGbC6EduL9LfAm/+9TxHN07506Q5AiaGieRXyM5aVMnv+id
         nVyRa9hAfniUMIAhbptLDFYK210MRFajddVIeWZTocjdggBM9p9wa7dSCNEF3x0tNwBF
         m0fj23NZ/R0RXW3+t5QJr0J4VKIs/uHf0qt2HSjQ7TlHIPBXxRDW2wuPYg7mpZ6yQgAm
         TOZfs1xd48EDaxK36coNlrx2AIyDKilyV8XsEBJI/nCfKEEScuBnTb21btS0pRDSknts
         Vc/A==
X-Gm-Message-State: AAQBX9c4Q5IRHhtRsfI6rbAw8xLPGN+eYDcLwZNI3GhNKmoHg4tnxGjQ
	H65Y+n6+35i6jSRZhBJVcePVgzyoyT/Prlygm4WI5zs7t4BTXIteGrM=
X-Google-Smtp-Source: AKy350bntKRaMCWVWN2EBYKosSpmYcwRTie0sf7QdGgSkje6tti18P3tm33PWkFx48cRZ0LkUgvDDNF4lfqn21Pv1Is=
X-Received: by 2002:a05:6870:1486:b0:180:b4c1:dfc3 with SMTP id
 k6-20020a056870148600b00180b4c1dfc3mr740030oab.7.1680538089018; Mon, 03 Apr
 2023 09:08:09 -0700 (PDT)
MIME-Version: 1.0
From: Greg McGary <gkm@rivosinc.com>
Date: Mon, 3 Apr 2023 09:07:58 -0700
Message-ID: <CACe4iF0ai9UcMWgoh98r1dyOd0b-Juqwox=m-twE_m7KKiqfYA@mail.gmail.com>
Subject: How to handle symbol indexes in gas and ld.bfd ?
To: binutils@sourceware.org
Content-Type: multipart/alternative; boundary="000000000000d3f53705f870c3a0"
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <binutils.sourceware.org>

--000000000000d3f53705f870c3a0
Content-Type: text/plain; charset="UTF-8"

I am implementing the RISCV Zisslpcfi extension. Without going into context
&
rationale for the new section, I will go straight to implementation
challenges.

I have a new section named .riscv.zisslpcfi_lp that contains a vector of
pairs
(<symbol>, <label>). <symbol> is represented as an index into the symbol
table--the same way that symbol references are represented in relocation
records--and <label> is a 32-bit integer.

The .riscv.zisslpcfi_lp section is ...

1) written by gas,
   resolving asymbol* to symndx

2) read & parsed by ld.bfd,
   resolving input symndx to riscv_elf_link_hash_entry*

3) written by ld.bfd when the output is relocatable,
   resolving riscv_elf_link_hash_entry* to output symndx

#1 is easy: write from _bfd_riscv_elf_set_section_contents() which
uses _bfd_elf_symbol_from_bfd_symbol() to get the symndx

#2 is easy: from _bfd_riscv_elf_merge_private_bfd_data(), parse
symndx and retrieve the symbol hash entry via
sym_hashes[symndx - symtab_hdr->sh_info]

#3 seems impossible without refactoring. There is no API for mapping
a symbol hash entry to its output symndx. The relocation code, which
also needs to transform input symndx into output symndx, does it
within elf_link_input_bfd() via the temporary flinfo->indices[] vector.

Moreover, gas internally uses asymbol* (struct bfd_symbol) while ld.bfd
uses symbol hash entries, which presents challenges for writing a generic
_bfd_riscv_elf_set_section_contents()

G

--000000000000d3f53705f870c3a0--