From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25777 invoked by alias); 17 Mar 2014 12:25:51 -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 25757 invoked by uid 89); 17 Mar 2014 12:25:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f179.google.com Received: from mail-lb0-f179.google.com (HELO mail-lb0-f179.google.com) (209.85.217.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 17 Mar 2014 12:25:48 +0000 Received: by mail-lb0-f179.google.com with SMTP id p9so3554862lbv.38 for ; Mon, 17 Mar 2014 05:25:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.153.9.72 with SMTP id dq8mr56697lad.62.1395059145226; Mon, 17 Mar 2014 05:25:45 -0700 (PDT) Received: by 10.114.172.199 with HTTP; Mon, 17 Mar 2014 05:25:45 -0700 (PDT) In-Reply-To: <10414444.6eOdp1cvY6@ws-gergap> References: <7365721.BnaR1nHazz@lt-gergap> <10414444.6eOdp1cvY6@ws-gergap> Date: Mon, 17 Mar 2014 12:25:00 -0000 Message-ID: Subject: Re: New feature "source-id" From: Matt Rice To: Gerhard Gappmeier Cc: gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00358.txt.bz2 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.