From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) by sourceware.org (Postfix) with ESMTPS id 8BD993858D28 for ; Tue, 3 Oct 2023 07:44:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8BD993858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-59f6041395dso7668457b3.1 for ; Tue, 03 Oct 2023 00:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696319077; x=1696923877; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4ZVBwwtbaIsmpPnRJot6fadgJ11JZwgsLILA4Qqvl1A=; b=Dgqxa4jQlIEaCEgzNVusdqmDkzWULWxtYRPTXz9rT7/BqD/y0FZiC6nq9/U/gL81yT TyEA3nufFn0Gr+ZOBdizwoviI3e9kXVFbh3zzX0N1EUF+zqTgN0UQkMb+v+hzzZcYGFh heAOjoDidT/EsmpQbXx7MUAtNGVNG/xboiLHO1whAyHmOLe4tpt5/Q91MBHeucoo5Nn+ H3nwQzB9jcKSefaQQlNSAqMUvWdNclflrSwVMcD9PvH/bd6B301uSOLpo8mxwACZ5Ol9 +MwSKoYrE4SVwEWwxq+zKoxFAEs9b7hhYh1j3cOR7SamsRYTCjGTO+A+hPLAz+KiSJZ6 oBXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696319077; x=1696923877; h=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=4ZVBwwtbaIsmpPnRJot6fadgJ11JZwgsLILA4Qqvl1A=; b=bPaXlc9JLlRaTR4VhdVkKgoZJXQPt1K/GcMNwTeptFVYRHFFHWF5tqCs3z0PIU14o+ 2bk5HbK4Bdz63W8y2tebhjkLdxtjnBfkJQp7i3/xdONKhFes/8djgyS5dhqMvVodtRpy /JjCccM59JMo4MkqlI1M97ZTNneF+AIFhrAItUn4d0vrjOS7SxwAnkGvU9l0Y6ckL66L M9wY9FMsVyZWd12tkCFotktvrHuh0hsxp6onlmGyjEtuJIrN5kz5yhcoU0NI68qnJh0a PmEB+F9pleRCqN1VdaN/Qlj1FMLLO39MsPbN27vOiyh2XFYPhedSjfXEZq7+YAjIE9jn HbOQ== X-Gm-Message-State: AOJu0YxN8SNiX3GBhuZU9f4gWE8QJVPEfnB1q2Wxhz6Vax+BZ0ArsDLb hbIdQK50v2pL35R8NSiNWo2uNUZKGu8i4MFPJBg= X-Google-Smtp-Source: AGHT+IFR3qJNa5S7VviHJ7Q8fq/JnoL4jBFcywULElT+UYSR3W0ztn6Q5zx0id7ovw6BQtv8hcq0adWT+VRFgMK1tDs= X-Received: by 2002:a25:6f54:0:b0:d7c:3699:a9ea with SMTP id k81-20020a256f54000000b00d7c3699a9eamr13827596ybc.8.1696319076694; Tue, 03 Oct 2023 00:44:36 -0700 (PDT) MIME-Version: 1.0 References: <875y3pe2wh.fsf@oldenburg.str.redhat.com> In-Reply-To: <875y3pe2wh.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Tue, 3 Oct 2023 00:44:26 -0700 Message-ID: Subject: Re: [RFC] DT_X86_64_PLT* dependency To: Florian Weimer Cc: GNU C Library Content-Type: multipart/alternative; boundary="000000000000fdfff30606cb0f3d" X-Spam-Status: No, score=-3015.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: --000000000000fdfff30606cb0f3d Content-Type: text/plain; charset="UTF-8" On Mon, Oct 2, 2023, 6:26 PM Florian Weimer wrote: > * H. J. Lu: > > > When these tags are generated, the r_addend field of the > R_X86_64_JUMP_SLOT > > relocation stores the offset of the indirect branch instruction. > However, glibc > > versions which don't have this commit in glibc 2.36: > > > > commit f8587a61892cbafd98ce599131bf4f103466f084 > > Author: H.J. Lu > > Date: Fri May 20 19:21:48 2022 -0700 > > > > x86-64: Ignore r_addend for R_X86_64_GLOB_DAT/R_X86_64_JUMP_SLOT > > > > According to x86-64 psABI, r_addend should be ignored for > R_X86_64_GLOB_DAT > > and R_X86_64_JUMP_SLOT. Since linkers always set their r_addends to > 0, we > > can ignore their r_addends. > > > > Reviewed-by: Fangrui Song > > > > won't ignore the r_addend value in the R_X86_64_JUMP_SLOT relocation. > Such > > binaries will fail to run with these versions of glibc. I am working > > on a linker patch > > to add a glibc version dependency similar to GLIBC_ABI_DT_RELR for > DT_RELR. > > Although this commit has been backported to glibc 2.33/2.34/2.35 > > release branches, > > there may be 2.33/2.34/2.35 glibc binaries without the fix. > > Can we reuse the GLIBC_ABI_DT_RELR marker? > Do all versions of glibc with DT_RELR support also ignore r_addend? > > > Should binaries with DT_X86_64_PLT tags depend on glibc 2.36 or 2.33? > > I don't understand this question. The binaries will run on any system > that has the marker symbol. Or do you suggest to use an existing glibc > symbol version? > Yes, I am planning to use existing glibc symbol version. > Thanks, > Florian > H.J. --000000000000fdfff30606cb0f3d--