From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Roland McGrath <roland@hack.frob.com>,
linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>,
Kushal Das <kdas@redhat.com>
Subject: Re: Extending coredump note section to contain filenames
Date: Mon, 12 Mar 2012 20:08:18 +0100 [thread overview]
Message-ID: <20120312190818.GA25523@host2.jankratochvil.net> (raw)
In-Reply-To: <4F5E4757.705@redhat.com>
On Mon, 12 Mar 2012 19:58:31 +0100, Denys Vlasenko wrote:
> This is better, isn't it?
> Wouldn't it be nice if gdb would retrieve binary's name by itself?
Yes, that yum should have been executed automatically, instead of just
suggested by that:
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/ec/1fd70dbee0db36eff9527254d9d2bbfd260f13
But this is a user interface issue, it was discussed with PackageKit people
etc. but it went nowhere.
Sorry but I cannot code the whole OS myself including all the Gnome UI
interfaces.
> (BTW: nothing prevents it from checking build ids and refusing
> to use it if they don't match.)
And if they do not match it will need to run the yum command above anyway.
So why to code two ways where the first one (by filename) works only sometimes
while the second way works always? Isn't it easier to do it always just the
second way?
> >The build-id mapping server above always works and without races.
>
> But it is not always available. Some people don't want to be connected
> to internet; other can't be connected.
That 'yum' command above will run in some conditions without any Internet
connectivity. But in some cases it will have more bandwidth requirements than
a build-id server query.
This is about package management vs. network servers connectivity, this is
also partially distro dependent.
> Does it follow from the above that filenames are *never* useful?
They can be sometimes useful but they are superseded by build-ids; with
build-ids they can be safely ignored.
Regards,
Jan
next prev parent reply other threads:[~2012-03-12 19:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-09 17:13 Extending coredump note section to contain filenames Denys Vlasenko
2012-03-09 17:29 ` Jan Kratochvil
2012-03-12 12:05 ` Denys Vlasenko
2012-03-12 12:13 ` Denys Vlasenko
2012-03-12 16:53 ` Jan Kratochvil
2012-03-12 18:58 ` Denys Vlasenko
2012-03-12 19:08 ` Jan Kratochvil [this message]
2012-03-12 19:45 ` Denys Vlasenko
2012-03-12 22:07 ` Jan Kratochvil
2012-03-12 22:16 ` Jan Kratochvil
2012-03-13 12:12 ` Denys Vlasenko
2012-03-13 12:19 ` Jan Kratochvil
2012-03-12 22:21 ` H. Peter Anvin
2012-03-12 22:31 ` Jan Kratochvil
2012-03-13 0:16 ` H. Peter Anvin
2012-03-13 0:27 ` Jan Kratochvil
2012-03-13 0:31 ` H. Peter Anvin
2012-03-13 0:36 ` Jan Kratochvil
2012-03-13 0:42 ` H. Peter Anvin
2012-03-13 0:46 ` Jan Kratochvil
2012-03-13 0:50 ` H. Peter Anvin
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=20120312190818.GA25523@host2.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=dvlasenk@redhat.com \
--cc=kdas@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=roland@hack.frob.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