All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>,
	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 17:50:12 -0700	[thread overview]
Message-ID: <4F5E99C4.7060305@zytor.com> (raw)
In-Reply-To: <20120313004642.GA19090@host2.jankratochvil.net>

On 03/12/2012 05:46 PM, Jan Kratochvil wrote:
> On Tue, 13 Mar 2012 01:42:18 +0100, H. Peter Anvin wrote:
>> There is no 100% reliable solution possible -- you have no guarantee of
>> any kind that the library executable still exists.
> 
> I have guarantee that the library binary mapped in memory identified by
> build-id can be found out there in the could.  There is no other guarantee.
> And this guarantee fails with other solutions.
> 
> If you say that it is _additional_ info to build-id then yes, one can always
> use build-id if everything else fails.  But then the non-build-id information
> is redundant and it can just lead to wrong toolchain solutions - which has
> already happened (Apport).

You're thinking of a particular use case which isn't necessarily the
only one that matters.  It might be the only one that matters to *you*,
but that's very different to what matters to a developer, for example.

And yes of course the build-id should be included.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


      reply	other threads:[~2012-03-13  0:50 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
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 [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=4F5E99C4.7060305@zytor.com \
    --to=hpa@zytor.com \
    --cc=dvlasenk@redhat.com \
    --cc=jan.kratochvil@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.