public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Luis Machado <luis.machado@arm.com>, binutils@sourceware.org
Cc: nd@arm.com
Subject: Re: Commit: Option to disable the use of debuginfod
Date: Thu, 10 Mar 2022 15:48:32 +0000	[thread overview]
Message-ID: <f61535f4-f921-04b8-9dc7-c2533eedac36@redhat.com> (raw)
In-Reply-To: <55f0c650-f1fe-445e-35c2-cf881c479b13@arm.com>

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


      reply	other threads:[~2022-03-10 15:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10  9:11 Nick Clifton
2022-03-10  9:28 ` Luis Machado
2022-03-10 15:48   ` Nick Clifton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f61535f4-f921-04b8-9dc7-c2533eedac36@redhat.com \
    --to=nickc@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=luis.machado@arm.com \
    --cc=nd@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).