This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: New feature "source-id"
- From: Matt Rice <ratmice at gmail dot com>
- To: Gerhard Gappmeier <gerhard dot gappmeier at ascolab dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Mon, 17 Mar 2014 05:25:45 -0700
- Subject: Re: New feature "source-id"
- Authentication-results: sourceware.org; auth=none
- References: <7365721 dot BnaR1nHazz at lt-gergap> <CADPb22RX30L=95ST8H+PfWKzEj3Erw1_9HXa1a+7-G0iGDC_kw at mail dot gmail dot com> <CADPb22QSYj0RRy-HOVUrU_GgFHRbfkEjeysa4-AFkNL5uxQDhw at mail dot gmail dot com> <10414444 dot 6eOdp1cvY6 at ws-gergap>
On Mon, Mar 17, 2014 at 1:49 AM, Gerhard Gappmeier
<gerhard.gappmeier@ascolab.com> wrote:
> On Sunday, March 16, 2014 09:22:17 AM Doug Evans wrote:
>> On Sat, Mar 15, 2014 at 7:34 PM, Doug Evans <dje@google.com> 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.