From: Tom Tromey <tromey@redhat.com>
To: Bruce Dawson <bruced@valvesoftware.com>
Cc: "'Gerhard Gappmeier'" <gerhard.gappmeier@ascolab.com>,
"gdb-patches\@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: New feature "source-id"
Date: Wed, 21 May 2014 19:30:00 -0000 [thread overview]
Message-ID: <874n0jhqui.fsf@fleche.redhat.com> (raw)
In-Reply-To: <2AC155A009400B4C8B05D518E4819AEF1A347F70@exchange10.valvesoftware.com> (Bruce Dawson's message of "Tue, 18 Mar 2014 17:56:14 +0000")
>>>>> "Bruce" == Bruce Dawson <bruced@valvesoftware.com> writes:
Bruce> I understand that some Linux distributions already make source
Bruce> packages for each package that they distribute, and this technique
Bruce> offers some unique advantages.
Bruce> However, this is orthogonal to the source-id proposal. Source-id's
Bruce> offer different value that is complementary.
Bruce> Our build system spits out dozens of builds a day. Some of these are
Bruce> run by developers, others by testers, and others by customers. Any one
Bruce> of them might crash. I might end up debugging (live debugging or a
Bruce> core file) any one of these builds, perhaps weeks after it was
Bruce> created. Because we have the source-id system set up I know that I can
Bruce> walk up and down the stack and have the source files automatically
Bruce> show up, with *zero* effort on my part. I don't' have to install
Bruce> source packages, I can have multiple core files from multiple versions
Bruce> loaded simultaneously. Only the source files that I need are
Bruce> downloaded so it is *extremely* efficient. Retrieving the needed
Bruce> source files is essentially instantaneous and requires zero developer
Bruce> effort.
I wonder if you considered an approach based on build-ids.
You'd start with the existing build-id feature. Then when your build
completes, you would record a build-id -> source-id mapping. Finally
you would have a small fuse filesystem that looks up the build-id in the
database and fetches the appropriate source tree from git.
One benefit of this approach is that it requires nearly no changes in gdb.
This avoids a lot of bikeshedding ;)
I found a few git/fuse projects on github.
If you considered this & rejected it, I'd be curious to know why.
If it doesn't meet your needs then I probably misunderstood what you are
going for.
FWIW the SRPM-based approach we use at Red Hat is pretty good, but not
truly great. It has a hack in the rewriting step and sometimes the
source tree layout isn't preserved properly somehow.
So something like the above may be more desirable overall.
Tom
next prev parent reply other threads:[~2014-05-21 19:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-15 10:49 Gerhard Gappmeier
2014-03-15 17:32 ` Doug Evans
2014-03-15 20:06 ` Eli Zaretskii
2014-03-16 2:34 ` Doug Evans
2014-03-16 9:43 ` Gerhard Gappmeier
2014-03-16 16:22 ` Doug Evans
2014-03-16 16:34 ` Eli Zaretskii
2014-03-17 8:49 ` Gerhard Gappmeier
2014-03-17 12:25 ` Matt Rice
2014-03-17 19:01 ` Gerhard Gappmeier
2014-03-18 0:25 ` Doug Evans
2014-03-18 0:48 ` Bruce Dawson
2014-03-18 1:39 ` Doug Evans
2014-03-18 17:44 ` Bruce Dawson
2014-03-18 17:57 ` Doug Evans
2014-03-18 13:22 ` Mark Wielaard
2014-03-18 14:00 ` Gerhard Gappmeier
2014-03-18 15:03 ` Mark Wielaard
2014-03-18 16:40 ` Gerhard Gappmeier
2014-03-18 17:56 ` Bruce Dawson
2014-05-21 19:30 ` Tom Tromey [this message]
2014-05-21 20:42 ` Bruce Dawson
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=874n0jhqui.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=bruced@valvesoftware.com \
--cc=gdb-patches@sourceware.org \
--cc=gerhard.gappmeier@ascolab.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