From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) by sourceware.org (Postfix) with ESMTPS id 306D73857C47 for ; Mon, 14 Feb 2022 13:00:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 306D73857C47 Received: by mail-ot1-x334.google.com with SMTP id b17-20020a9d4791000000b005a17fc2dfc1so11560400otf.1 for ; Mon, 14 Feb 2022 05:00:10 -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=FD4luJhqQ81WRN3GsRgjY7R/lNRNudG+BI/q56K2KvU=; b=b6E6t+diECWwNtM3o9OQP1XB8M0yGrChE6v3yOIDqnwyG/xHOmeE0t/u0gBQs2deDl mPPf3d7OMsNYXCMs95jMaJ4n9YMkJYWxSpne9ZHAcZ5L0WhkfY8BhCE4pPLN5/LKP9X4 V1HTl0KFzLggh25qOTX55lVrFceGAysm80ML48ORvI6qDIJKmY9kWolElO4U6hIDK+fs fvw3tDrFaawqXll7gLxRhwBGPZHL7G341tInobsfXZrZ7rBwRroRtPpNGOmGKmfFpeZb 5uRcoyxp/Uq8RLwh2p/v7LHiU6Ea7dQBaYFTFOdULMylrL6maaswkgR4jzapRbfNNRi5 e8Rg== X-Gm-Message-State: AOAM531IbJ77s9Y8xuNOtVTblq1y+coN4dckMlHY0YqLjLfPIFDHWxRP x1gsD7gK24wXNZnGRoLxfpx3NA== X-Google-Smtp-Source: ABdhPJwINubgyrH237/u0QWl8hfIf6t7N+9h+LaTsvixuyUaUhPlpCmfexGnHmBxWsHfLOg1CqT63Q== X-Received: by 2002:a9d:6848:: with SMTP id c8mr4782123oto.4.1644843609554; Mon, 14 Feb 2022 05:00:09 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:6747:70ce:2039:9f74:f513? ([2804:431:c7cb:6747:70ce:2039:9f74:f513]) by smtp.gmail.com with ESMTPSA id k19sm12286009oot.41.2022.02.14.05.00.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Feb 2022 05:00:09 -0800 (PST) Message-ID: <8da69301-2650-a38d-2e96-665a7ba14c8d@linaro.org> Date: Mon, 14 Feb 2022 10:00:06 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH] Linux: Consolidate auxiliary vector parsing (redo) Content-Language: en-US To: Florian Weimer Cc: libc-alpha@sourceware.org References: <87y22hqh2w.fsf@oldenburg.str.redhat.com> <662fface-5af4-5094-a0ae-b37e56de837d@linaro.org> <87ee4563t9.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: <87ee4563t9.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 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=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, 14 Feb 2022 13:00:12 -0000 On 14/02/2022 09:16, Florian Weimer wrote: > * Adhemerval Zanella: > >> I still think this approach is still fragile since we don't how if this >> will be the only optimization option gcc will make loops to memset. We >> already have a similar problem on _dl_start, but it is slight different >> since the clear memory should be done before self-relocation. Also for >> memset.c itself there is no much we can do, so we need to resort on >> -fno-tree-loop-distribute-patterns. >> >> However in this case I think it would be better to avoid hacking the >> compiler and expect it does not generate broken code and instead assume >> memset *might* be generate and work around it. We already have the >> hack on sysdeps/generic/symbol-hacks.h, so I think we should do something >> similiar: >> >> 1. Add a __memset_generic internal symbol on all ports to avoid the >> iFUNC plt (which seems to be cause of this issue). >> >> 2. Add a symbol redirection to call such symbol when required (most >> likely in the dl-start.h as H.J has suggested. >> >> So we don't need to handle this specific issue everytime we hack into >> the loader code. > > But this isn't a new problem, right? > > I also don't think an assembler-based symbol redirect is more portable > than -fno-tree-loop-distribute-patterns. We need to build these parts > with -ffreestanding, and we need a portable way (across GCC and Clang) > to redirect the four required functions ('memcpy', 'memmove', 'memset' > and 'memcmp', according to the GCC manual). I don't think -ffreestanding will help much in this specific issue. The problem is mainly that for some architectures, memcpy, memmove, memset, and memcmp might be implemented as a iFUNC and it might no be relocated at the time of the call. At least redirecting the calls to internal symbols avoid this specific issue.