From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by sourceware.org (Postfix) with ESMTPS id D96283858C27; Mon, 18 Oct 2021 22:27:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D96283858C27 Received: by mail-pj1-x1035.google.com with SMTP id na16-20020a17090b4c1000b0019f5bb661f9so1143536pjb.0; Mon, 18 Oct 2021 15:27:37 -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=52cKl2jDZTyKUgxoyUdU4hN0J5b0CAaBNWmRbGF/XnQ=; b=wIrG1twtaA4U/OfAriSS/DB7ZVpkXPLMrlnxXfBj/xzseHA9b+E3xtgq4H+Xi8dLiy 18p5p8sUHsP62g4kF1B3q+9AMH/2aOY1VA5Iwr+0uzhBVDXPRZFEV34H9z21HePqvhkx sol/oW5vfv4aw0KFUKS066Q9qgyTvLU+dEHR0svZnvPIRB157KhQpum4bAw3RbueTCtt gbBmtwYqWhNo3VBwi2XI/EninE6TyboAhDg46ej/nVThIJwrXF1t49owex14nhmSYbdC eWrifxl1+NeqP1dI4+NXaP5cxQ8pT1aI357p18vvhsLqIuirdZKFljr8Utj9ltcB9IK2 H5FQ== X-Gm-Message-State: AOAM5335IDIJkgJKqHNxQDHMUrlVdVTMyvR9OyrQ9urwcvL/0qrVqvzm SZIUIEO77KDFxI25zWchmiTbwqCfalDzAzkOByw= X-Google-Smtp-Source: ABdhPJzXdPWLxpjHLjB7oO4cIvH2E6A8d/+gi6PTy3WmuM1pF5HDgzQoB6j+FGfObB//qePZRwD8ZwfhrNr+Vvbex7c= X-Received: by 2002:a17:90a:9292:: with SMTP id n18mr1877576pjo.120.1634596056930; Mon, 18 Oct 2021 15:27:36 -0700 (PDT) MIME-Version: 1.0 References: <20211017005020.2645717-1-maskray@google.com> <20211018181530.yz62n64dgn2kd4oe@google.com> <20211018191902.vcf3u5s7h5losxyt@google.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 18 Oct 2021 15:27:00 -0700 Message-ID: Subject: Re: [PATCH v2] elf: Support DT_RELR relative relocation format [BZ #27924] To: Joseph Myers Cc: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= , GNU C Library , Binutils Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3023.7 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: Mon, 18 Oct 2021 22:27:39 -0000 On Mon, Oct 18, 2021 at 2:10 PM Joseph Myers wrot= e: > > On Mon, 18 Oct 2021, F=C4=81ng-ru=C3=AC S=C3=B2ng via Libc-alpha wrote: > > > I know. I have mentioned that the situation is not different from many > > previous situations where a compatibility check may not catch > > everything. > > That also applies to many changes to glibc functions. > > We use symbol versioning when adding new symbols, or when changing a > symbol in a way incompatible with existing binaries making valid use of > glibc APIs. We rarely use it when adding a new feature to an existing > symbol (for example, a new flag for a function that takes a flags > argument, or providing stricter guarantees about a return value that > wasn't fully specified before), even though in fact binaries using the ne= w > feature would not work correctly when run with older glibc versions. > > I don't think a new ELF feature is that different from new features added > to existing functions. If a binary requires a new glibc to run, running it with the old glibc will lead to an ld.so diagnostic message. DT_RELR shouldn't be different. --=20 H.J.