Re: New feature "source-id"

Matt Rice
2014-03-17T12:25:51Z

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.