Martijn van Oosterhout wrote:
> On Wed, Mar 28, 2007 at 02:16:55PM -0400, Joseph S wrote:
>> I thought the performance penalty came from making the executable
>> bigger, which means the executor has to skip over the debug symbols
>> somehow, which eats up cpu. If the symbols are in a different file this
>> wouldn't apply.
>
> When running the executable is mmaped into memory. So any extra data in
> the executable has absolutly zero effect.
>
Good to know. I'll always compile with debug info from now on.
>> Well I don't really know how debug symbols work. It seems that maybe
>> all the debug info is is the source files with some mappling info then
>> maybe it might.
>
> No, the info is in the debug info (gdb can't be expected to understand
> the source of every language you might want to debug).
I slipped up a little when typing that. What I meant to say is that the
files that are dumped into /usr/src/debug seem to be .c and .h files,
with one binary file. If that binary file is a map that matches
statements in the executable to text in the .c and .h then it could be
possible for those files to be generated w/o having to recompile the
executable, but no one here seems to know how to do that, so I'll just
have to recompile and restart.