From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15388 invoked by alias); 17 Mar 2014 19:01:57 -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 15379 invoked by uid 89); 17 Mar 2014 19:01:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: moutng.kundenserver.de Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 17 Mar 2014 19:01:51 +0000 Received: from smtp.ascolab.com ([213.95.4.182]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0M4HXH-1XFfDN3MV1-00rnic; Mon, 17 Mar 2014 20:01:46 +0100 Received: from localhost (localhost [127.0.0.1]) by smtp.ascolab.com (Postfix) with ESMTP id 37A36E0BD8 for ; Mon, 17 Mar 2014 20:01:46 +0100 (CET) Received: from smtp.ascolab.com ([127.0.0.1]) by localhost (smtp.ascolab.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id i7-Rb_TgWLnS for ; Mon, 17 Mar 2014 20:01:43 +0100 (CET) Received: from ws-gergap.localnet (unknown [213.95.4.186]) by smtp.ascolab.com (Postfix) with ESMTPA id 1AD65E0BCB for ; Mon, 17 Mar 2014 20:01:43 +0100 (CET) From: Gerhard Gappmeier To: gdb-patches@sourceware.org Subject: Re: New feature "source-id" Date: Mon, 17 Mar 2014 19:01:00 -0000 Message-ID: <2739108.yJ4Vgng9gv@ws-gergap> User-Agent: KMail/4.11.5 (Linux/3.11.6-gentoo; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <7365721.BnaR1nHazz@lt-gergap> <10414444.6eOdp1cvY6@ws-gergap> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2049228.n1rtrNFVqD"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00395.txt.bz2 --nextPart2049228.n1rtrNFVqD Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Content-length: 2537 On Monday, March 17, 2014 05:25:45 AM you wrote: > On Mon, Mar 17, 2014 at 1:49 AM, Gerhard Gappmeier > > wrote: > > On Sunday, March 16, 2014 09:22:17 AM Doug Evans wrote: > >> On Sat, Mar 15, 2014 at 7:34 PM, Doug Evans wrote: > >> > Note that one concern I have is that it may be that some sites will > >> > want to have some of gdb's state updated when source files are > >> > automagically fetched. E.g., maybe one would want to update the > >> > source search path. Maybe not, but at any rate I don't want this > >> > feature to preclude doing things like that, and one can't do that if > >> > the feature works by running an external program via popen. > >> > >> As a data point, > >> another way to go is to just have a convention for some global > >> variables in the binary. > >> With the debug info gdb can access them, and they could contain > >> everything that would be in the .note section. > >> > >> I don't have a preference, per se. > >> I just mention it as a possibility, and if one went that route then > >> doing this in Python/Guile would be while perhaps not required > >> certainly easy. > > > > That's an interesting idea. When I first read this comment I thought it > > would require code changes what would not be what I want. But indeed we > > can simply generate an own 'vcsinfo.c' file which gets compiled and > > linked with the executable. I think its even simpler to add a new C file > > than requiring GNU as to generate a new section. > > > > example vcsinfo.c: > > /* this file was genarated, bla bla, don't modifiy */ > > static const char vcs_type[] = "git"; > > static const char vcs_url[] = "git@github.com:gergap/source-id.git" > > static const char vcs_version[] = > > "c2ec66e6a36451ba47422d186fd97311989ef278" > I think its weird to store this in .rodata instead of somewhere it can > be easily stripped, especially if you plan on adding the sha1 file > hashes through this same mechanism, since that is a less constant > size, though you did mention adding that to the debug info > specifically. I agree. That's a good point. I think we should stay with the original idea of having a .note section. It is also more consistent with the build-id feature. Another argument against adding this to the source might be code size. For small programs on embedded devices memory matters, so saving these strings would be a benefit. The .note section can be stripped and the feature would still work with the "separate-debug-info" approach. --nextPart2049228.n1rtrNFVqD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit Content-length: 198 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlMnRpcACgkQB81vglqsUMTN6wCgnA8J8d69KEjiYwy/d1mFxtvK FQIAn3jnAhkJN992nmLSAX2MMETuiZHO =5Vks -----END PGP SIGNATURE----- --nextPart2049228.n1rtrNFVqD--