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 A33E9212F7 for ; Tue, 19 Mar 2024 17:08:40 +0100 (CET) Received: (qmail 19746 invoked by uid 550); 19 Mar 2024 16:04:10 -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 19712 invoked from network); 19 Mar 2024 16:04:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710864507; x=1711469307; 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=1+nFhW+erah+OY0yUuH+r9WZQsM7ef+7eh1lQoXtg7w=; b=ko5Y2BH2fcjeV65DWVgChE5PHnHlK7jFLr/MxziOKsFsqwHwhvI3ONOgrluoK771XZ CY6yb4S1BuJqtHoIZDuzKsJ+QXMBJXgWFydavuRLFD0MySRvTNjk06W5AgrHF/MXGJ0H IjxFUtxbTrBDXYJQNIf94VrD+ZKPCGB45ik7TrFK+gGHI7xHQ2rdrvYkRdGP+anzfM3X CIG3oU3v8tFkkV6QS0PkrzUyad+s8NZOnyymtSwtG25WAzyenNIPFrvYzz/i6pcRLhgb ROpPOyiL+EqX5v9W8jf94YfoTKtbWaLito+wo31Ubbzw6B/A0e9AQVtfkqAj0WD4i9qi NqVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710864507; x=1711469307; 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=1+nFhW+erah+OY0yUuH+r9WZQsM7ef+7eh1lQoXtg7w=; b=NtTxn3krMMqM8TN/aYGD5be7i5MasD2jcfUIsynxwnfzMqA/BTEu151TYJqOzI7n7A fgXJFJy3o/S2mbgZZ179tkHTjygmGYMMKQrtpsiciEBLijbCy9hjOk96FEVwwsUeIdrj 2vK9qz61d7wMPX8FtzGojhW23R+pER8ITyB7Llxfc/VL3hTEyTCJ/ZirLDc2i+qNMWqS jbM8NwB7i0AiJ/ZGoJQZaU3J8yYojAYBqV7Kgy9DB9md0GcR36SsSB7P3yzTn/CiAjLg x/pbOEnBC1E34koohD7fANSoOJUpMVkZk91CG4E1cmhzl9/Ftk/yLRdvSq50KZwccPJC 1fVQ== X-Gm-Message-State: AOJu0Yyi1euoEW41XPbWNAHjCSLNBIYQRRZasKssaOuI7L95bb7a5+Tv o9RqegNom3VxHRi4nkE93lIfUsplPumsNUom+CDFmOHc2XPjpi6J/T0D1fJHsrjJAr93KwvlOT1 4FN31Yr/cIp90xzzG6Mgd1G5Dt7iLBfFv X-Google-Smtp-Source: AGHT+IGNiYN9NrDEImGN9Ex2Y9PkpPmOkrcFK/0vOgXd8TRsEbjtPePNjE9mau2UtLkuuUaEE176peDvZOq2WtqGdnc= X-Received: by 2002:a17:90a:c284:b0:29d:fefa:258d with SMTP id f4-20020a17090ac28400b0029dfefa258dmr8860038pjt.2.1710864506764; Tue, 19 Mar 2024 09:08:26 -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 09:08:15 -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: > > > > } else { > > > > size_t val =3D syms[R_SYM(rel[1])].st_value; > > > > for (j=3D0; val-segs[j].p_vaddr >=3D segs[j].= p_memsz; j++); > > > > *rel_addr =3D rel[2] + segs[j].addr - segs[j]= .p_vaddr + val; > > > > } > > > > } > > > > +#ifdef __xtensa__ > > > > + ((unsigned long *)dyn[DT_PLTGOT])[3] =3D segs[0].addr - segs[= 0].p_vaddr; > > > > +#endif > > > > > > Is this actually needed for anything? Generally musl doesn't use the > > > reserved GOT slots itself, and on all the other archs I'm aware of, > > > they're essentially reserved to the dynamic linker implementation so > > > the dynamic linker is just free not to use them and not to set them > > > up. > > > > xtensa doesn't have relative register jumps and calls, so local jumps > > and calls to a far off locations need to use absolute target addresses. > > One possible solution is to have the address in the GOT entry, the > > other is to calculate the target address using the text segment load > > offset at runtime. Both have the same instruction count, see > > http://wiki.osll.ru/doku.php/etc:users:jcmvbkbc:binutils-xtensa#local= _call > > for the details, but the latter doesn't waste GOT space and that saves > > a noticeable amount of RAM. > > I see. Doesn't this limit you to a single text segment, though? In > practice it might not matter, but it's more constraining than fdpic > was designed to be. Instead of a fixed dedicated GOT entry there can be multiple entries, one per independent text segment, giving the maximum of 1024 / 4 - 3 =3D 253 text segments addressable with this technique. Instead of generating a fixed load from GOT + 12 there would be a relocation against that load instruction mentioning the target symbol and the linker would have a chance to allocate GOT space, fix up offsets in these instructions and add dynamic relocations against these GOT entries that would produce runtime load offsets for the corresponding text segments. --=20 Thanks. -- Max