This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New feature "source-id"


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]