From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10918 invoked by alias); 21 Jun 2018 17:16:07 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 819 invoked by uid 89); 21 Jun 2018 17:15:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=Hx-languages-length:1897 X-HELO: mail-qt0-f196.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3rJpyuocdc843yA1ej47GwE0aVLIFEBaCwymI0p3qZU=; b=jAswFKunNoNTMQNM8kc6MOfigWXoXNlKElG4LWgNHsY+J5u5B7JL1/JjKBzp9+zsAf bksbSA/nj5P6xMlBVRij5DDwIkFeQzjbXC8H//39L2RwYbQSzmsp5Y2FAP2KRcf3WJeC Vnhw2kJTIZORe4albv7MkAq92DvuT6NPNfYsXgKj9DTllcz1Ve62OvalF90WvJn+RIKY GpdrISeU2/tRW2NTtJvp/7VTChlEosvxhFvNAo0f2gk38uNeJlP7Lhf8npYd03o/dS+i GxilYhYeHLpyao4ONd9lUAcIE7ymtB44rlGtymeTB6tfaJXv1tiNWI6e2JoLVNvEmrWX 0YeA== X-Gm-Message-State: APt69E0A2jfev82xX6its3QIDmg0Ut8nyCukNc8krXIVWGVGv5E+z7XE oO7p2XyHDtNjZym4+IFURDp9hf0o1A4= X-Google-Smtp-Source: ADUXVKJnLi9YLAOtAUDZzFR0svBabMaSnNXwy1Syl+dQf1iAbf8u4zRYK/AI3mq3bzXmcgCHRUuU0Q== X-Received: by 2002:ac8:29fd:: with SMTP id 58-v6mr22873321qtt.174.1529601321083; Thu, 21 Jun 2018 10:15:21 -0700 (PDT) Subject: Re: Why GLIBC requires compiler optimizations to build To: Gary Benson Cc: "H.J. Lu" , Adhemerval Zanella , GNU C Library References: From: Carlos O'Donell Message-ID: <3393b12d-3c81-ddf2-4ef6-6902c274a521@redhat.com> Date: Thu, 21 Jun 2018 17:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00685.txt.bz2 On 06/20/2018 11:22 AM, Gary Benson wrote: > On 20 June 2018 at 13:51, Carlos O'Donell wrote: >> On 06/20/2018 06:35 AM, Gary Benson wrote: >>> On 11 June 2018 at 22:48, H.J. Lu wrote: >>>> On Mon, Jun 11, 2018 at 2:38 PM, Adhemerval Zanella wrote: >>>>> It has been some time since I tried to build glibc without optimization >>>>> as an exercise and I can't really recall what exactly has prevented me >>>>> to accomplish it. So the question is if it is make sense to add such >>>>> requirement and if it is the case whether it would be a useful options >>>>> and what prevents us to do so? >>>> >>>> The main issue is to bootstrap ld.so to prevent dynamic relocations >>>> before it is ready. >>> >>> Is it only really elf/rtld.c that specifically requires optimization then? >> >> No. >> >> The dynamic loader has many functions it needs to execute the early startup. >> >> So there are a lot of dependencies on other *.c files here and there, which >> must be callable directly and not through the PLT. > > Ok. Thanks for explaining this. > >> The perfect solution is a refactored build system that can distinguish what >> is going into rtld that needs optimizations and what is not. Then apply >> optimizations only to rtld. >> >> Even then, for debugging purposes, I have gotten away with using gcc's >> function attributes to mark some function as -O0 to debug them more easily, >> otherwise it's very hard to debug and _dl_debug_printf() is your highest >> value tool. > > I did not know about __attribute__ ((optimize ())), thank you! I couldn't live without it when debugging complex code bases where using -O0 makes the bug go away or breaks rtld in this case... so you can use the function attribute to alter just a function at a time. Cheers, Carlos.