From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26452 invoked by alias); 21 May 2014 20:42:18 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 26414 invoked by uid 89); 21 May 2014 20:42:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: smtp01.valvesoftware.com Received: from smtp01.valvesoftware.com (HELO smtp01.valvesoftware.com) (208.64.203.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 21 May 2014 20:42:15 +0000 Received: from [172.16.1.101] (helo=smtp.valvesoftware.com) by smtp01.valvesoftware.com with esmtp (Exim 4.76) (envelope-from ) id 1WnDKN-000411-6L; Wed, 21 May 2014 13:41:31 -0700 Received: from EXCHANGE10.valvesoftware.com ([fe80::995a:b010:5730:9af]) by fedex1.valvesoftware.com ([::1]) with mapi id 14.03.0169.001; Wed, 21 May 2014 13:42:13 -0700 From: Bruce Dawson To: 'Tom Tromey' CC: 'Gerhard Gappmeier' , "gdb-patches@sourceware.org" Subject: RE: New feature "source-id" Date: Wed, 21 May 2014 20:42:00 -0000 Message-ID: <2AC155A009400B4C8B05D518E4819AEF1A37DA61@exchange10.valvesoftware.com> References: <7365721.BnaR1nHazz@lt-gergap> <1905500.YOUlx3S3mT@ws-gergap> <1395154991.27876.65.camel@bordewijk.wildebeest.org> <1825450.WDlHRVxHcI@ws-gergap> <2AC155A009400B4C8B05D518E4819AEF1A347F70@exchange10.valvesoftware.com> <874n0jhqui.fsf@fleche.redhat.com> In-Reply-To: <874n0jhqui.fsf@fleche.redhat.com> x-exclaimer-md-config: 86b76815-e903-4403-b95d-5abb05264373 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00514.txt.bz2 I did consider doing a fuse file system. It could work, and would minimize = the changes needed to gdb. I'm not aware of any specific problems but I sus= pect it would add some extra complexity, and might make it difficult to avo= id some problems. But, as you say, if it gets it done then that counts for = a lot. Presumably such a system would use the Python hooks (that I currentl= y use) in order to configure the fuse file system. One potential problem with the fuse file system is with loading source file= s with matching file names. Let's say we have server.so and client.so and b= oth have a file called foo.c. In an ideal world the debug information would= contain a full path to foo.c and we could use "set substitute-path" to rem= ap from the two different build directories to two different fuse file syst= ems, and life would be good. Unfortunately the reality is that many project= s (including libc6) put incomplete paths into the debug information. If sou= rce-id was a first-class feature of gdb then when the debugger needed "foo.= c" for server.so it would look in the source-mapping information in server.= so.dbg, find the version control information, retrieve the file, and load i= t. If source-id is not a first-class feature of gdb then I see no way to se= t up source search paths such that the right version would be loaded at the= right time. We could try to fix every build system in the world to embed f= ull paths, but that will never happen. This failure case is real. On the other hand, it is rare enough that a sour= ce-id system that ignored it would still be incredibly useful. > Then when your build completes, you would record a build-id -> source-id = mapping.=20=20 Where would the build-id -> source-id mapping be stored? The method we curr= ently use is to have a section in the debug file which contains the mapping= from source files to the version control identifiers. This feels like a si= mple and reliable method to record the mapping. We've been using it for ove= r a year, and similar techniques have been used for many years on other pla= tforms, so it is a proven technique. -----Original Message----- From: Tom Tromey [mailto:tromey@redhat.com]=20 Sent: Wednesday, May 21, 2014 12:30 PM To: Bruce Dawson Cc: 'Gerhard Gappmeier'; gdb-patches@sourceware.org Subject: Re: New feature "source-id" >>>>> "Bruce" =3D=3D Bruce Dawson writes: Bruce> I understand that some Linux distributions already make source=20 Bruce> packages for each package that they distribute, and this=20 Bruce> technique offers some unique advantages. Bruce> However, this is orthogonal to the source-id proposal.=20 Bruce> Source-id's offer different value that is complementary. Bruce> Our build system spits out dozens of builds a day. Some of these=20 Bruce> are run by developers, others by testers, and others by=20 Bruce> customers. Any one of them might crash. I might end up debugging=20 Bruce> (live debugging or a core file) any one of these builds, perhaps=20 Bruce> weeks after it was created. Because we have the source-id system=20 Bruce> set up I know that I can walk up and down the stack and have the=20 Bruce> source files automatically show up, with *zero* effort on my=20 Bruce> part. I don't' have to install source packages, I can have=20 Bruce> multiple core files from multiple versions loaded simultaneously.=20 Bruce> Only the source files that I need are downloaded so it is=20 Bruce> *extremely* efficient. Retrieving the needed source files is=20 Bruce> essentially instantaneous and requires zero developer 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 compl= etes, 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 go= ing for. FWIW the SRPM-based approach we use at Red Hat is pretty good, but not trul= y 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