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.
