From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id EF78D3AA8887 for ; Mon, 23 May 2022 12:35:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EF78D3AA8887 Received: by mail-oi1-x235.google.com with SMTP id e189so17580666oia.8 for ; Mon, 23 May 2022 05:35:39 -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:in-reply-to :content-transfer-encoding; bh=YI5Rs4O/c4dbc02zUblAdFIvEq+6BfOgvZljnd5KgLI=; b=gCf+PhjI5Hz0nxiRelvVuYjrvIVKgVTvZIbRo/0n81qWy82YpYqV66vRHb+/iLwEtJ 7nu3QEfv1BuuFKDOX7fqdvclcgU/TWioNiAsfwi4cFt3IGI53gcEv9jUntpptMwyoEZl SsEQMGXc7+dmpRkf6pobpHb4AqJfcRO7dH4aqQUNXsgkXBdPPL4KlFB0Gd8MWTqnD1zA yIcIiMwMvi9KprLDCfIALeWxSVhIp7OBINqHd1MOVvFxnIKNXH6dbA72Qgv1B8Ig3V0/ kZITdwERAbE3AJ+rcpFnhz+Rjq5WTt9NRnEHecz2pi15Hys5UXh3lgNUKqFDCrO0SteO eQrQ== X-Gm-Message-State: AOAM530TXb9rko2LDIFEw7YNKkwbD0VStXz65mT9sXV7uNrqB17HZh8k mjx7eaQ0JvFNb93Xn8NAIemu03tQw48G9A== X-Google-Smtp-Source: ABdhPJzRo7bwFaXMeScTho7wCA8cj6+gr2BOcqNeFJy5t8+nmqq6RG/JFM/ir9DwfABc1fY3WW5ptg== X-Received: by 2002:a05:6808:1986:b0:32b:52ba:5484 with SMTP id bj6-20020a056808198600b0032b52ba5484mr1418033oib.166.1653309337725; Mon, 23 May 2022 05:35:37 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:9f85:58f2:612:a11d:c380? ([2804:431:c7cb:9f85:58f2:612:a11d:c380]) by smtp.gmail.com with ESMTPSA id eq37-20020a056870a92500b000e686d13883sm3965551oab.29.2022.05.23.05.35.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 May 2022 05:35:37 -0700 (PDT) Message-ID: <94dbef38-5719-13f6-43a1-9a63367e217e@linaro.org> Date: Mon, 23 May 2022 09:35:34 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v3] elf: Rewrite long RESOLVE_MAP macro to a debug friendly function Content-Language: en-US To: Fangrui Song , Siddhesh Poyarekar Cc: Nicholas Guriev , libc-alpha@sourceware.org References: <20220514224849.d7isxwcxnxoo3jhc@google.com> <20220522222425.hk5vde2erkyadxol@google.com> From: Adhemerval Zanella In-Reply-To: <20220522222425.hk5vde2erkyadxol@google.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, KAM_SHORT, 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 23 May 2022 12:35:42 -0000 On 22/05/2022 19:24, Fangrui Song via Libc-alpha wrote: > On 2022-05-15, Siddhesh Poyarekar wrote: >> On 15/05/2022 04:18, Fangrui Song wrote: >>> On 2022-05-14, Nicholas Guriev wrote: >>>> On Пн, 2022-05-09 at 19:08 +0530, Siddhesh Poyarekar wrote: >>>>> Please use __always_inline instead, which adds the inline keyword as >>>>> well as __attribute__ ((inline)).  That way gcc ensures that the >>>>> function is *always* inlined. >>>> >>>> That is not necessary. My original intention was to improve the >>>> debugging experience at this point. And the standard `inline` keyword >>>> allows one to control optimizations with the -O flag. >> >> You can't build glibc with anything less than -O2, so that's a moot point.  If you don't use __always_inline here then you're not only changing the debugging experience, but also potentially adding a performance overhead.  gdb can do well enough in most cases of inlined functions, so __always_inlined should not hamper that. > > Hope that the -O2 requirement can be lifted:) > > The original decision might be related to guaranteed inlining and relocations in -O0 > but it should be revisited nowadays... (Both FreeBSD rtld and musl rtld allow -O0). I tried some time ago, before the recent refactors, and the loader still fails at bootstrapping (I have not dig into to pinpoint exactly what has failed). But I agree it would be good to support it, we also might need to fix some objecting pulling from loader (since -O0 messes with symbols and the script to decide what to pull). > >>> Looks good to me, I think the always_inline here does not affect >>> performance, as shown in my testing with a large PIE with many >>> R_*_RELATIVE (function call overhead is larger with a non-R_*_RELATIVE). >> >> If you want to make a decision based on this then please quantify it more precisely with a microbenchmark added to benchtests.  Otherwise just add __always_inline because it is a more minimal change.  TBH I'd prefer the former because it then adds a new microbenchmark that we can measure dynamic linker changes in future but I can live with the latter. > > Thanks. I can add __always_inline. > (I don't think it matters but I guess I just want to avoid a debate :)) I think the main issue is we build glibc with -fgnu89-inline, which is required due some optimizations where a function is defined without inline, but then it has an inline definition to be used internally. Also, since we don't use -Winline we can't assure that compiler won't emit the function definition where gcc documents it might [1]. So I think one exercise we might do it to remove all __always_inline__, and add -Winline to see which functions, if any, won't be inline by compiler. I would like also to eventually remove -fgnu89-inline, since I think we can restructure the code to not rely on extern inlines nor on the internal inline optimizations. Also, it seems that although clang seems to support -fgnu89-inline, it has subtle different semantics that breaks some internal glibc assumptions. [1] https://gcc.gnu.org/onlinedocs/gcc/Inline.html