RE: New feature "source-id"

[Bruce Dawson <bruced@valvesoftware.com>]

I better understand what you are doing now with the .c file now. Previously I had assumed that you would be compiling it and then linking the .o file along with all of the others.

Now I am confused about *why* you are compiling it. If you have a text file that has the source information then why not just add it as a custom section directly? What is the value in compiling it into a .o file first?

> I can imagine generating a .c file (say, could even be .S) from the post-link binary that contains source information

Don't forget that this text file is generated from both the source files listed in the post-link binary *and* from the version control information for these files.

-----Original Message-----
From: Doug Evans [mailto:dje@google.com] 
Sent: Monday, March 17, 2014 6:39 PM
To: Bruce Dawson
Cc: Gerhard Gappmeier; gdb-patches
Subject: Re: New feature "source-id"

...
I can imagine generating a .c file (say, could even be .S) from the post-link binary that contains source information, compile it, and then using objcopy to add the resultant section with the source information into the resultant binary.  The key here being that source file information gets put in a specific section so it's easy to do this.  If one is splitting the debug information into a separate file, one could objcopy --add-section the source-file-section there instead.
 There's no real "relinking" here.  I don't see the difference with what you're doing now.
...