From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 654132C72A for ; Tue, 19 Mar 2024 16:25:35 +0100 (CET) Received: (qmail 12054 invoked by uid 550); 19 Mar 2024 15:21:05 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 12022 invoked from network); 19 Mar 2024 15:21:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710861922; x=1711466722; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vNV11KpOCPuWBkkqoVMasPhmcUdt8u6rZ7O4whsDSBw=; b=bQ1wzGDxtiy4LxYwZlW9fwrfIlKX8BBONRwdj79+AU2hnMFyDL9kkLhVOa6I1JEs7X RorOHPlrrrFQCuJY+Iodilj0PYvcBI0yT4sGncgl+9/Ogsf870oURCmAWMtg/iKPdsEy 6fk+uT8hfgIB+5cyUL2VEf3QuhA9F8xom5fgxRBQcTLp1GgVFN3PA+ZaR85ywpZIa8aI HtV8La385j7e6ekiKvN1LVpcQqTa8mQcbdL3vbRfVKYYOGcjYUmYAbplb9OeUAIHfs+P EbbWujw1uNhwziu3RUGWHRndAYPMhINcB0zVzktl7MqCc+Mqmgy0WayO1BozPWh2glIN U2QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710861922; x=1711466722; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vNV11KpOCPuWBkkqoVMasPhmcUdt8u6rZ7O4whsDSBw=; b=rbyYTyYfQf4otXGleJw9Ttpa9WAkZJzOq9PGULGqUe4Yuofc4wD5waSg5fSiSrx7M4 S6/QAMIh3pJCF11P9bP+Ko5Pnt9M7ROcFlzKlmtvcR5COxLfS4IxLkh7MAZySh/iWiUu onob3ba4IVTr8K/l+h65iFmTu7BwWxa6w9XeKuWiaSvO9GKi46LrsJsQ7sKaAgnw88os 94aSJ9h5KBansbvP2Qh2pZyyQLsqT6wSeOIc5RIT5D/xQLO6hWtDlbGEO2mttZeLPIXS C5003X53TN7hlXHUMEkxk30eukH+dzLn6RZq9cCt3m9VZY11SyvUbO9lIKR1ic1ydOwt WLEw== X-Gm-Message-State: AOJu0YzUfiJBkqNKtMIf9g8jVksFF6A4n7rsx3FNlPfbS2oitIvNRwcZ nrqM2nWVSn6hiAg8EPcfBPvutqrVnFltFHvpVuawW61FibLBYazPSr15zk2NbPVhXdmiu1Zjjt4 FcLu/GKQOlRjJAW+IWLH1khG3+Gk= X-Google-Smtp-Source: AGHT+IHjTiYt4kYFO4kZHfNid0jf/AAO/ZnoMyuwVHiCE9idDKXmHB3lu3m/+MDIX9NX2SkAygkuKJIWBgkopUMu0H8= X-Received: by 2002:a17:90a:d48c:b0:29d:e349:13c4 with SMTP id s12-20020a17090ad48c00b0029de34913c4mr12147528pju.18.1710861921615; Tue, 19 Mar 2024 08:25:21 -0700 (PDT) MIME-Version: 1.0 References: <20240227232430.GM4163@brightrain.aerifal.cx> <20240228001303.GN4163@brightrain.aerifal.cx> <20240228183032.GO4163@brightrain.aerifal.cx> In-Reply-To: <20240228183032.GO4163@brightrain.aerifal.cx> From: Max Filippov Date: Tue, 19 Mar 2024 08:25:10 -0700 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Initial xtensa/fdpic port review On Wed, Feb 28, 2024 at 10:30=E2=80=AFAM Rich Felker wrot= e: > On Wed, Feb 28, 2024 at 09:20:33AM -0800, Max Filippov wrote: > > On Tue, Feb 27, 2024 at 4:12=E2=80=AFPM Rich Felker w= rote: > > > > diff --git a/ldso/dlstart.c b/ldso/dlstart.c > > > > index 259f5e18..beca953f 100644 > > > > --- a/ldso/dlstart.c > > > > +++ b/ldso/dlstart.c > > > > @@ -90,12 +90,19 @@ hidden void _dlstart_c(size_t *sp, size_t *dynv= ) > > > > - segs[rel_addr[1]].p_vaddr > > > > + syms[R_SYM(rel[1])].st_value; > > > > rel_addr[1] =3D dyn[DT_PLTGOT]; > > > > + } else if (R_TYPE(rel[1]) =3D=3D REL_RELATIVE) { > > > > + size_t val =3D *rel_addr; > > > > + for (j=3D0; val-segs[j].p_vaddr >=3D segs[j].= p_memsz; j++); > > > > + *rel_addr +=3D segs[j].addr - segs[j].p_vaddr= ; > > > > > > So xtensa has a "relative" reloc type that's just adjusted by the loa= d > > > offset of the segment the relocation lives in, rather than needing to > > > use a symbolic relocation referencing a section symbol like other > > > fdpic archs do? > > > > I was looking at the ARM BFD code while doing that and > > my impression was that they do the same. > > Regardless, I wonder why either relocation form might be preferable? > > I think the relative type here is perfectly acceptable. At first I > thought it was weaker (less capable of representing addresses of > objects in different segments), but looking again, I don't think > that's the case. I found that this treatment of the REL_RELATIVE is not consistent with the REL_RELATIVE treatment in do_relocs(), where RELA type relocation is expected to have an addend, and only the addend matters, not the initial value of the field being relocated. I just realized that looking at what ARM does might not be a good idea for the xtensa port, as ARM uses the REL type relocations and xtensa uses RELA. Also do_relocs() does not use the DSO load map, so the following change is required for it to work in the FDPIC case: case REL_RELATIVE: - *reloc_addr =3D (size_t)base + addend; + *reloc_addr =3D (size_t)laddr(dso, addend); break; --=20 Thanks. -- Max