From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id D10C7385702C; Tue, 12 Oct 2021 14:10:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D10C7385702C Received: by mail-pg1-x52a.google.com with SMTP id q5so5944951pgr.7; Tue, 12 Oct 2021 07:10:31 -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=CGEQxAJtI3GPAU2tWVGMPM5n54XnyUJLL98njQubQjg=; b=G2M4auv9kAp8ZV+7Ke34yq2/cqnXSxll62pIHvk/YCD00rep8gMwefVQ5j6ScLus// v3NvHNEdYEUZsaBVPfEO20nGl2M2laY5lzv6YSyGdHip6KZgxzreZgmHNYO+AtID+9U1 J4Xt1JOcnbxOJRSrQJ6RQgJEGEM4SD/kDWeDHML3TqxuHmMLzTOk3/ijtMgW31tWkCoh kBLnvnbEaDLB4e9apBklFpxFNqarwQn9KBO4V3xA51yVvw19bgYS7oeEka/FVkv724Bk YbaZGoeK3c+zflcYn2XuHOEZj2YwEAMFn3JCKtjlM2Iw2ahiJAu0ujU90H3aPvHEMgJW EqWg== X-Gm-Message-State: AOAM533IDKPAtxS/QUtUqCSL3/bat+D8PiEtMhmtKGUGau6ds88OiI9a 6u4gBnOLI5sDbuMQcEhQ0uE/f50ar3PL7VqAtBg= X-Google-Smtp-Source: ABdhPJxkFSuxF2oyLSxBGOm0tYgeFQL4/iGKJ0UtZ8IaSG7s7xR6TtU7NnyzGIn08HAz3yMoMrxi9XV0N0nl1HkVhfo= X-Received: by 2002:a05:6a00:b95:b0:44c:7c8b:f762 with SMTP id g21-20020a056a000b9500b0044c7c8bf762mr32341868pfj.60.1634047830842; Tue, 12 Oct 2021 07:10:30 -0700 (PDT) MIME-Version: 1.0 References: <20211008065740.1485737-1-maskray@google.com> <3368ef30-eb8c-8828-1af0-1a227d99dc93@suse.com> In-Reply-To: From: "H.J. Lu" Date: Tue, 12 Oct 2021 07:09:55 -0700 Message-ID: Subject: Re: [PATCH] elf: Support DT_RELR relative relocation format [BZ #27924] To: Jan Beulich Cc: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= , libc-alpha@sourceware.org, binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3024.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: Tue, 12 Oct 2021 14:10:33 -0000 On Tue, Oct 12, 2021 at 1:18 AM Jan Beulich via Libc-alpha wrote: > > On 11.10.2021 20:43, F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > 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, stru= ct r_scope_elem *scope[], > >>> # define ELF_DYNAMIC_DO_RELA(map, scope, lazy, skip_ifunc) /* Nothi= ng 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= _un.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-li= nux-gnu-gcc > > CXX=3D/tmp/glibc-many/install/compilers/ia64-linux-gnu/bin/ia64-glibc-l= inux-gnu-g++ > > make -j 50 > > I didn't suggest the build would fail. What I said is that I don't > think the code is correct there. > > > 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:) > > But you realize that I took ia64 only as example, as that's where > I know ABI (pointer size) and ELF container size aren't connected. > As per my looking at merely EF_MIPS_* in context of reading > Joseph's reply, it might be that MIPS is another such example. But > I lack sufficient knowledge of MIPS ... > The new code should be tested and verified on all supported targets. That is another reason to implement this in binutils ld first. --=20 H.J.