From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by sourceware.org (Postfix) with ESMTPS id 6D79B3858D28 for ; Tue, 14 Dec 2021 12:23:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D79B3858D28 Received: by mail-qt1-x82e.google.com with SMTP id p19so18099042qtw.12 for ; Tue, 14 Dec 2021 04:23:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=/s4WKGxrrl1bkisHahiPWr54BCnW2jkZLVrxjKXj5LY=; b=pzngNApYZVmZp78ZWerXuEeSuSZelHSkWPofV02SrS9J44FyoxLPiO+robhYX+jXR4 HHH5E1pzFBa13eU4eYPgHQvf9WU1Ao4pi9numyhiHiU2T7Q+1T/5sd56NSIri42wO592 RdJCvju7dnDG9pnTVG4Cq7pVjTB0nYMpPfWsd2VOBNz2hG+hUFzoBVGbpk9elN9IVJbS NadLboCc3yQgx1PQQRK0yDGAnWkx3eNy5r25IEn3PAIScxGdbh4rqjrE72f5btB4uhQp LQyI77RBptyBe+FXyxHgjToejm69FpXOyRmVOChePVRG5tb7nBNYPCOmQCaJmh8i6wAm /OnA== X-Gm-Message-State: AOAM532121IJBcBHcoRH6hff4Yr2DwKLxZsMY4maNB8B8ApbK20Vaj6J tu1vzgczMfeINoi+GiSh1AaGdxwEwURglA== X-Google-Smtp-Source: ABdhPJy9MCBrwL4RLRZEvu5+bl8tL+ujc76T+2tzwxi33tL/uc9xqKygtucYOlnewFOwG3NY9/SUHA== X-Received: by 2002:a05:622a:1306:: with SMTP id v6mr5523872qtk.115.1639484615069; Tue, 14 Dec 2021 04:23:35 -0800 (PST) Received: from ?IPV6:2804:431:c7ca:a776:8dc8:480e:fc02:618b? ([2804:431:c7ca:a776:8dc8:480e:fc02:618b]) by smtp.gmail.com with ESMTPSA id y11sm12759462qta.6.2021.12.14.04.23.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Dec 2021 04:23:34 -0800 (PST) Message-ID: Date: Tue, 14 Dec 2021 09:23:33 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH] elf: Add elf checks for main executable Content-Language: en-US To: Florian Weimer , =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: GNU C Library References: <20211119150329.2200675-1-adhemerval.zanella@linaro.org> <87bl1tmtxz.fsf@oldenburg.str.redhat.com> <873a6969-8c06-5233-2b4c-48360e120f07@linaro.org> <877dchlbb8.fsf@oldenburg.str.redhat.com> <6386c389-086d-e123-d4d6-a97777f207ed@linaro.org> <87czm8quz3.fsf@oldenburg.str.redhat.com> <871r2nmmaf.fsf@oldenburg.str.redhat.com> <20211214001742.lbleuljd2dgmfinx@google.com> <87sfuvsgll.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: <87sfuvsgll.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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, 14 Dec 2021 12:23:36 -0000 On 14/12/2021 06:03, Florian Weimer wrote: > * Fāng-ruì Sòng: > >> If the question is: "if upstream glibc implements the diagnostic, will >> ChromeOS port the patch to their glibc". My reply is non-authoritative, >> but if this has not been a problem for more than 3 years now, I do know >> see large value backporting the feature to their older glibc release. > > But if you don't backport, you can teach your toolchain to start > producing binaries that fail to load on older glibc. You will have to > keep creating binaries that lack proper markup. > > My concern is that we go through all this trouble to implement a version > proper handshake, and yet Google binaries will still crash on older > glibc. Is ChromeOS glibc really binary compatible with glibc from other general Linux distributions? Different from google/grte branches, ChromeOS seems to work by patching upstream glibc and my impression is they not really care nor aim to be (Fāng-ruì remarks also strength this idea). In any case, ChromeOS's DT_RELR use does show that it is de facto a different ABI, it is only unfortunate that its ELF ABI does not give us any standard marking to advertise so (and we will need to resort on some hacking such as scanning for some symbol or versioning to to do). I am not sure if we should really care to handle such situations, it would be nice if we can coordinate with ChromeOS to get it align its ABI with mainstream and sort DT_RELR but I think *now* it is not a requisite and I think we should move DT_RELR support independently.