Re: New feature "source-id"

[Doug Evans <dje at google dot com>]

On Mon, Mar 17, 2014 at 12:01 PM, Gerhard Gappmeier
<gerhard.gappmeier@ascolab.com> wrote:
>> > 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.

I agree the consistency of .note is nice, but I wouldn't preclude
people wanting something different.
Getting something into a .note section may involve more build changes
than some group may want to take on.

> 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.

Technically, even if the info was added to the source (so to speak),
it needn't affect code size.
I can imagine all of these (so called) global variables being put in a
specific section which is put in a non-loadable segment.

The solution in gdb needn't preclude any implementation, that is up to
the script.
So, assuming the community wants this feature, let's separate out how
the source information is obtained from how gdb uses it.

btw, If Python doesn't have a library for reading ELF files, it should.
Thus we needn't hardcode anything about where the data lives into gdb
- leave it to the externally supplied script.