From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id 67F7A3857C79 for ; Tue, 12 Jul 2022 10:22:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 67F7A3857C79 Received: by mail-ot1-x32a.google.com with SMTP id y10-20020a9d634a000000b006167f7ce0c5so5837618otk.0 for ; Tue, 12 Jul 2022 03:22:03 -0700 (PDT) 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:organization:in-reply-to :content-transfer-encoding; bh=WyvkaV+w79QQHXVhrPyJdITk+YgGgLXXI4C5GiBoj1I=; b=FeCspYrTlL9jth0QSI/hRyHJNhjlmpBQzwS3Mcqu0J6EFCqDkZiXVqjGkNg0dwVoAG lsj9MCv7lO35hmMNzuia9T3nmPcU1e8cMERVX2dLthvSVBqtL9nvo33xaiOmkkr/teMt RzBWCYfojrOavxugGfQ4+kGJZ75zF0p5W5gOZqfHWvde7Wv8FTqWo9+mvF4Ee/saC5vN bfQrJGDn+owdK62N/SP9J3pFVb6ARZZjI7btZ2xtFh1bFonF++9/vF6ZSrAbrQq3LQzU jz1dw4uKcvk9CzYEi2b04fo6FxY7+3LQBeJf/r2TMKigzR7I3n7LmuwxeWb15/OcjFbV sEIw== X-Gm-Message-State: AJIora/XUKbdF/9vmiogtXqJMcAnPFkiH51+uBSOAQ4ym4B29FfXe/uz Ju+AqZUfXX6mt/ufIU+BtfAr+Q== X-Google-Smtp-Source: AGRyM1uIdWhgHLSr6hvLSgs7tWi7OL4icCloOWylaeLXnZYdTul6/Gb9UZd3YFiOwmdmDYYbkeWvrQ== X-Received: by 2002:a9d:5f1a:0:b0:61c:50a1:df3 with SMTP id f26-20020a9d5f1a000000b0061c50a10df3mr2935151oti.102.1657621322609; Tue, 12 Jul 2022 03:22:02 -0700 (PDT) Received: from [12.18.8.156] ([201.46.27.6]) by smtp.gmail.com with ESMTPSA id i19-20020a056871029300b0010c17e6c699sm4289675oae.47.2022.07.12.03.21.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jul 2022 03:22:02 -0700 (PDT) Message-ID: <612c015a-8d77-d0ee-773a-c51e9cb1d239@linaro.org> Date: Tue, 12 Jul 2022 07:21:57 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.0.2 Subject: Re: glibc 2.36 - Slushy freeze (3 weeks to release) Content-Language: en-US To: Xi Ruoyao , WANG Xuerui , Fangrui Song , Alan Modra Cc: Carlos O'Donell , libc-alpha , binutils@sourceware.org, caiyinyu , liuzhensong References: <7aba5486-ac02-2088-221e-513a6892817a@linaro.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 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, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2022 10:22:07 -0000 On 12/07/22 06:24, Xi Ruoyao wrote: > On Tue, 2022-07-12 at 14:42 +0800, WANG Xuerui wrote: > >> It's generally nice to be able to remove dubious/superfluous/unused >> code, but doing so must not negatively affect users. I'm personally in >> support of removing such code, but as others have pointed out, it's >> unfortunate that the LoongArch port turns out to have "inherited" the >> wart from elsewhere, so the removal should not be done lightly (and >> break users' systems). > > I can live with either > > (1) Fix Binutils-2.39 ASAP and remove R_LARCH_NONE handling in Glibc. > And document "To build Glibc-2.36 or any code link to Glibc-2.36 for > LoongArch, Binutils >= 2.39 is needed." > (2) Work around R_LARCH_NONE in Glibc rtld code. > > The advantage of (1) is we can get rid of "some stupid code" and make > some marginal performance gain. The disadvantage is we are too close to > the deadline (glibc-2.36 and binutils-2.39 due date) and if we fail > we'll wait for another 6 months to upstream Glibc. > > But, "just remove R_LARCH_NONE in Glibc rtld and tell everyone to build > Glibc-2.36 (and everything link to it) for LoongArch with > /path/to/not/reviewed/binutils.git/some-fancy-branch" is not acceptable > to me. So from a reviewer perspective, what should I use to actually build a working toolchain where I can actually run the loader and libc using qemu? I am currently using git branch of gcc 12, binutils 2.38, and qemu master and I still can't get the loader to work correctly with qemu user. This is not really a blocker, but it would be good to have some validation that current port is actually working somehow and not dependent on further fixes or backports.