From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by sourceware.org (Postfix) with ESMTPS id 4F4E03858D35 for ; Mon, 11 Oct 2021 18:43:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4F4E03858D35 Received: by mail-yb1-xb29.google.com with SMTP id g6so41180339ybb.3 for ; Mon, 11 Oct 2021 11:43:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Xv1+S107YNmrxDHmy++DjmeFEZSk2BudlK461JyA8Q4=; b=hjuenzpT4rFppu0Rz5z0d/8TvZ9/dNdnMyCo6+LPpJAhTWCj96zbfv8xIlalu+rM5y xFi/Gve+Vg3ZVYskaHoq2OnSzLqTNblrs7FC8RWaV3etuLDTdd9JOxhhvsFz8i9UILJI jukqr7iuHK7ZqHM/ykJoPFAnXgaucfe1EhsDeyaT37nz/UYNLbzrcfn4kSzUiXIRLJxM q+ZpMOGZ36AHWNz5lp1TRKFrpJvJ2mmrUizbp4b/oeLnInXpyeLnKpcScfS6Yxa++b7y NfeejYBOjBt4k//BSsrpRuIP1q1x6ncVQtSOhbWVDPOFSINab1Q4bNrmghBgGofS775k FsTg== X-Gm-Message-State: AOAM530P9/oes74SlRFmEQRLDzv1P1KsskKFWA34j/CbqMobfPCVLjEx TK1Mg2KIz8v0+r0Tmiwvqv/iSl2GroBP3kE+KUHR9IAS3Z45XA== X-Google-Smtp-Source: ABdhPJwG9AuLgpH0aILqUpD5EtU1mhE5ixJWbcu/CdCtpZgv0ibB67F1Kocsqir5X7kNpRTRt3fsxdM9PkQEQ+Ohzas= X-Received: by 2002:a25:bdc5:: with SMTP id g5mr24695205ybk.403.1633977834675; Mon, 11 Oct 2021 11:43:54 -0700 (PDT) MIME-Version: 1.0 References: <20211008065740.1485737-1-maskray@google.com> <3368ef30-eb8c-8828-1af0-1a227d99dc93@suse.com> In-Reply-To: <3368ef30-eb8c-8828-1af0-1a227d99dc93@suse.com> From: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Date: Mon, 11 Oct 2021 11:43:42 -0700 Message-ID: Subject: Re: [PATCH] elf: Support DT_RELR relative relocation format [BZ #27924] To: Jan Beulich Cc: binutils@sourceware.org, libc-alpha@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-16.2 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 18:43:56 -0000 On Mon, Oct 11, 2021 at 12:48 AM Jan Beulich wrote: > > On 08.10.2021 08:57, Fangrui Song via Binutils wrote: > > --- a/elf/dynamic-link.h > > +++ b/elf/dynamic-link.h > > @@ -192,6 +192,33 @@ elf_machine_lazy_rel (struct link_map *map, struct= r_scope_elem *scope[], > > # define ELF_DYNAMIC_DO_RELA(map, scope, lazy, skip_ifunc) /* Nothing= to do. */ > > # endif > > > > +# define ELF_DYNAMIC_DO_RELR(map) = \ > > + do { = \ > > + ElfW(Addr) l_addr =3D (map)->l_addr, base =3D 0, start; = \ > > + const ElfW(Relr) *r =3D 0, *end =3D 0; = \ > > + if (!(map)->l_info[DT_RELR]) = \ > > + break; = \ > > + start =3D D_PTR((map), l_info[DT_RELR]); = \ > > + r =3D (const ElfW(Relr) *)start; = \ > > + end =3D (const ElfW(Relr) *)(start + (map)->l_info[DT_RELRSZ]->d_u= n.d_val); \ > > + for (; r < end; ++r) { = \ > > + ElfW(Relr) entry =3D *r; = \ > > + if ((entry & 1) =3D=3D 0) { = \ > > + *((ElfW(Addr) *)(l_addr + entry)) +=3D l_addr; = \ > > + base =3D entry + sizeof(ElfW(Addr)); = \ > > + continue; = \ > > + } = \ > > + ElfW(Addr) offset =3D base; = \ > > + do { = \ > > + entry >>=3D 1; = \ > > + if ((entry & 1) !=3D 0) = \ > > + *((ElfW(Addr) *)(l_addr + offset)) +=3D l_addr; = \ > > + offset +=3D sizeof(ElfW(Addr)); = \ > > + } while (entry !=3D 0); = \ > > + base +=3D (8 * sizeof(ElfW(Relr)) - 1) * sizeof(ElfW(Addr)); = \ > > While in line with the proposed spec additions I'm afraid the uses of > ElfW(Addr) here aren't universally correct: You assume that ELF > container type (size) expresses an aspect of the ABI. While this is > indeed the case for several arch-es, I think this has been a mistake. > IA-64, while meanwhile mostly dead, is (was) an example where 64-bit > code can validly live in a 32-bit ELF container (at least as far as > the psABI is concerned; I have no idea whether glibc actually > followed the spec). There's a separate ELF header flag indicating the > ABI, and hence the size of a pointer. Thanks for chiming in. As of ia64 buildability, it works for me: scripts/build-many-glibcs.py /tmp/glibc-many compilers ia64-linux-gnu mkdir -p out/ia64; cd out/ia64 ../../configure --prefix=3D/tmp/glibc/ia64 --host=3Dia64-linux-gnu CC=3D/tmp/glibc-many/install/compilers/ia64-linux-gnu/bin/ia64-glibc-linux-= gnu-gcc CXX=3D/tmp/glibc-many/install/compilers/ia64-linux-gnu/bin/ia64-glibc-linux= -gnu-g++ make -j 50 As of the actual functionality, ugh, I cannot find ia64 in my Debian testing's qemu-user-static package:( So I cannot test. That said, gold and LLD don't support ia64. If we have a concern that ia64 may not work, the GNU ld maintainers can simply not add ia64 support:) I hope that means we don't need ELF_MACHINE_NO_RELR. > > --- /dev/null > > +++ b/elf/tst-relr.c > > @@ -0,0 +1,20 @@ > > +static int o, x; > > +void *arr[] =3D { > > + &o, &o, &o, &o, &o, &o, &o, &o, &o, &o, &o, &o, &o, &o, &o, &o, > > + 0, > > + &x, &x, &x, &x, &x, &x, &x, &x, &x, &x, &x, &x, &x, &x, &x, &x, > > +}; > > Personally I consider this overly simplistic a testcase. The two > sequences are fully identical, have no gaps except for the one in > the middle, and there's also no interleaving / mixing of pointers. > None of this should matter as the specific symbol the relocation > is for is not supposed to be of interest, but in a testcase you > want to make sure none of this has an effect. > > I also wonder whether it is a good idea to have a testcase with > "fundamentally" different behavior on 32-bit vs 64-bit: The former > will require two RELR entries afaict, while the latter will get > away with one here. Thanks for the test suggestion. I can use some fancy patterns. > Jan > > > +static int > > +do_test (void) > > +{ > > + for (int i =3D 0; i < 16; i++) > > + if (arr[i] !=3D &o) > > + return 1; > > + for (int i =3D 17; i < 33; i++) > > + if (arr[i] !=3D &x) > > + return 1; > > + return 0; > > +} > > + > > +#include > > > --=20 =E5=AE=8B=E6=96=B9=E7=9D=BF