From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 0FD673858429 for ; Thu, 10 Mar 2022 15:48:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0FD673858429 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-453-1lC_PVYrPEyFYGbYRxTkhA-1; Thu, 10 Mar 2022 10:48:34 -0500 X-MC-Unique: 1lC_PVYrPEyFYGbYRxTkhA-1 Received: by mail-wr1-f72.google.com with SMTP id n4-20020a5d4844000000b001f1ed76e943so1836365wrs.22 for ; Thu, 10 Mar 2022 07:48:34 -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 :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=FQj+m1pM9IRTFFOdtGI2WIOIJ9h4Z/a85tD0W1qvjXg=; b=VUrN8EYL2F9ZO+qaMJ/pDN1aY8KP5fHyGYKEviZCg4vpM/rIPw+sFvg9s/y9UFETSP A/gemJ4eZUro7pRuteoTbHzVSF6MBPxKi6egIHXvPdWCcKbxX9v23hYDKX9Cp4iQ0517 RR7UnZJiiXCPy3JgUsfttvEWGMvrzez83Co8GnduuOs8LWGeAlahC83urkm7Ag3fpsK2 tBDZ25WimacbnqH6haFvTGAUoKqrdl2FrNwl/WTvkWbzM0DRCDYGzgGY0F0xZ+ruy6VZ BSBs6HDTwN4Azy8ktpYx9eDdaXc0M5a1f8v2MFfVq0JVFDYT4R0JuVxodYbA5K8Fn3bt UZDA== X-Gm-Message-State: AOAM533oa4Elr6aRPBFjFh5mFTN8ICl7eYuvnGTQI20hI/RtTpMZMTAt ApcM6G21G1CY7coecf4UsQxJeKJ82jeZIpupYgHi56GfVLpMMuNXWUMa72sAbQmigHcIIg/ewWp KAxipKYQ8cD0KMl9cCw== X-Received: by 2002:adf:cd8a:0:b0:1f0:9cf:d8be with SMTP id q10-20020adfcd8a000000b001f009cfd8bemr4190036wrj.153.1646927313488; Thu, 10 Mar 2022 07:48:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJwkMBaNpyZVcP/vwz9lVCm3XzHZ0OUSgBZ3jjWmlUPrC5n644usb89XulJnXgA0MCBgWjAOgQ== X-Received: by 2002:adf:cd8a:0:b0:1f0:9cf:d8be with SMTP id q10-20020adfcd8a000000b001f009cfd8bemr4190025wrj.153.1646927313271; Thu, 10 Mar 2022 07:48:33 -0800 (PST) Received: from [192.168.1.6] (adsl-2-solo-173-39.claranet.co.uk. [80.168.173.39]) by smtp.gmail.com with ESMTPSA id bg20-20020a05600c3c9400b0037fa5c422c8sm8866821wmb.48.2022.03.10.07.48.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Mar 2022 07:48:32 -0800 (PST) Message-ID: Date: Thu, 10 Mar 2022 15:48:32 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 To: Luis Machado , binutils@sourceware.org Cc: nd@arm.com References: <874k4641g1.fsf@redhat.com> <55f0c650-f1fe-445e-35c2-cf881c479b13@arm.com> From: Nick Clifton Subject: Re: Commit: Option to disable the use of debuginfod In-Reply-To: <55f0c650-f1fe-445e-35c2-cf881c479b13@arm.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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: 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: Thu, 10 Mar 2022 15:48:43 -0000 Hi Luis, >>    I have recently seen several bug reports about readelf and objdump >>    unexpectedly slowing down.  The problem turns out to be due to >>    attempts to access debuginfod servers which are either not there or >>    just slow to respond.  So to help alleviate this problem I am applying >>    the patch below which adds a new command line option: > > If it slows things down by default, shouldn't we change the default to > disabled (I'm assuming it is enabled by default) Yes, it is enabled by default. I did think of changing the default to be "disabled" but then this would mean introducing a conflict between the current binutils and future binutils releases. Plus my feeling is that it is better to provide the user with as much information as possible by default, since these tools are basically used when investigating something. Skipping information because it might slow things down ought to be definite action taken by the user rather than a default action taken by the tool. > and/or look into improving the code so it doesn't slow things down? Well the slow down is in the debuginfod client library code, or more accurately in the communication with the servers, so there is not a lot that we can do on our end. At least I don't think so. Maybe there is a timeout setting that we could tweak. I have to confess that I am not exactly an expert in the debuginfod code... Cheers Nick