Re: New feature "source-id"

[Gerhard Gappmeier <gerhard dot gappmeier at ascolab dot com>]

On Monday, March 17, 2014 05:25:45 AM you wrote:
> 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.
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.

Attachment: signature.asc
Description: This is a digitally signed message part.