we are dealing with very tight space limitations, so we cannot put a full
debug build on our device. We are currently getting a crash, so we put a
non-debug version of the code on the device and got the core file. We
then loaded the core file into gdb and did a file command against a debug
version built from the same source. Is this valid? Will the backtrace be
valid? Or do we have to get a core from the debug version for backtrace
to be valid?
Joseph Witherspoon <jspoon@us.ibm.com> wrote:
we are dealing with very tight space limitations, so we cannot put a full
debug build on our device. We are currently getting a crash, so we put a
non-debug version of the code on the device and got the core file. We
then loaded the core file into gdb and did a file command against a debug
version built from the same source. Is this valid? Will the backtrace be
valid? Or do we have to get a core from the debug version for backtrace
to be valid?
By non-debug version, do you mean a version compiled with optimization
on, or do you mean a version compiled for debug, then debug information
stripped out?
If you compile for debug, then strip the debug information out, then
put the stripped executable on the device, what you are trying to do
will be valid and useful. (But, the debug compiled, then stripped,
version will be bigger than the optimized version, but far smaller
than the version with full debug. At a guess, 10-50% bigger than
optimized, and about 1/5th the size of full debug.)
-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
We normally make release build with symbols (-g -O3 etc), then store it
somepalce, put stripped
version into the staging environment, and then, if it crashes, the coredump
can be analyzed with
gdb <path-to-re;ease-binary-with symbols> .
Debug builds are used mainly during development.
BR,
Roman
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:chngig$8rg$1@inn.qnx.com…
Joseph Witherspoon <> jspoon@us.ibm.com> > wrote:
we are dealing with very tight space limitations, so we cannot put a
full
debug build on our device. We are currently getting a crash, so we put
a
non-debug version of the code on the device and got the core file. We
then loaded the core file into gdb and did a file command against a
debug
version built from the same source. Is this valid? Will the backtrace
be
valid? Or do we have to get a core from the debug version for backtrace
to be valid?By non-debug version, do you mean a version compiled with optimization
on, or do you mean a version compiled for debug, then debug information
stripped out?If you compile for debug, then strip the debug information out, then
put the stripped executable on the device, what you are trying to do
will be valid and useful. (But, the debug compiled, then stripped,
version will be bigger than the optimized version, but far smaller
than the version with full debug. At a guess, 10-50% bigger than
optimized, and about 1/5th the size of full debug.)-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
Roman Pavluyk <john@eleks.lviv.ua> wrote:
We normally make release build with symbols (-g -O3 etc), then store it
somepalce, put stripped
version into the staging environment, and then, if it crashes, the coredump
can be analyzed with
gdb <path-to-re;ease-binary-with symbols> .
That works, too – though the mapping from executable back to source
for an optimized executable can sometimes be “odd”.
-David
Debug builds are used mainly during development.
BR,
Roman“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:chngig$8rg$> 1@inn.qnx.com> …
Joseph Witherspoon <> jspoon@us.ibm.com> > wrote:
we are dealing with very tight space limitations, so we cannot put a
full
debug build on our device. We are currently getting a crash, so we put
a
non-debug version of the code on the device and got the core file. We
then loaded the core file into gdb and did a file command against a
debug
version built from the same source. Is this valid? Will the backtrace
be
valid? Or do we have to get a core from the debug version for backtrace
to be valid?By non-debug version, do you mean a version compiled with optimization
on, or do you mean a version compiled for debug, then debug information
stripped out?If you compile for debug, then strip the debug information out, then
put the stripped executable on the device, what you are trying to do
will be valid and useful. (But, the debug compiled, then stripped,
version will be bigger than the optimized version, but far smaller
than the version with full debug. At a guess, 10-50% bigger than
optimized, and about 1/5th the size of full debug.)-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
–
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
David Gibbs wrote:
Joseph Witherspoon <> jspoon@us.ibm.com> > wrote:
we are dealing with very tight space limitations, so we cannot put a full
debug build on our device. We are currently getting a crash, so we put a
non-debug version of the code on the device and got the core file. We
then loaded the core file into gdb and did a file command against a debug
version built from the same source. Is this valid? Will the backtrace be
valid? Or do we have to get a core from the debug version for backtrace
to be valid?By non-debug version, do you mean a version compiled with optimization
on, or do you mean a version compiled for debug, then debug information
stripped out?If you compile for debug, then strip the debug information out, then
put the stripped executable on the device, what you are trying to do
will be valid and useful. (But, the debug compiled, then stripped,
version will be bigger than the optimized version, but far smaller
than the version with full debug. At a guess, 10-50% bigger than
optimized, and about 1/5th the size of full debug.)-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
By debug version, I mean we add the -g flag. We take the rest as
defaults, which does include some optimation (sh4 platform). I believe
our current approach is wrong, since we now know our backtrace is showing
the wrong routine (no way that routine is being executed at the time).
Can you be more specific in how I would compile for debug and then strip
the debug information out? And do I need to turn off optimization or
leave it default?
Thanks!
When I said debug version, I meant with the -g flag. We use the defaults
for the rest, which would include some optimization (sh4 platform). If I
understand, you are suggesting building a version with -g and then somehow
stripping debug info from the shared objects and executables? Can you
expand on that?
David Gibbs wrote:
Joseph Witherspoon <> jspoon@us.ibm.com> > wrote:
we are dealing with very tight space limitations, so we cannot put a full
debug build on our device. We are currently getting a crash, so we put a
non-debug version of the code on the device and got the core file. We
then loaded the core file into gdb and did a file command against a debug
version built from the same source. Is this valid? Will the backtrace be
valid? Or do we have to get a core from the debug version for backtrace
to be valid?By non-debug version, do you mean a version compiled with optimization
on, or do you mean a version compiled for debug, then debug information
stripped out?If you compile for debug, then strip the debug information out, then
put the stripped executable on the device, what you are trying to do
will be valid and useful. (But, the debug compiled, then stripped,
version will be bigger than the optimized version, but far smaller
than the version with full debug. At a guess, 10-50% bigger than
optimized, and about 1/5th the size of full debug.)-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
Joseph Witherspoon <jspoon@us.ibm.com> wrote:
David Gibbs wrote:
By debug version, I mean we add the -g flag. We take the rest as
defaults, which does include some optimation (sh4 platform). I believe
our current approach is wrong, since we now know our backtrace is showing
the wrong routine (no way that routine is being executed at the time).
That could be part of the bug – if the stack has gotten corrupted, the
backtrace can be wrong. (Or, even, if the stack has gotten corrupted,
the return from a function can go to the wrong place, and an “impossible
at that time” function could actually be executing. Stack corruption can
be insidious that way.)
Can you be more specific in how I would compile for debug and then strip
the debug information out? And do I need to turn off optimization or
leave it default?
I think the tool for “stripping” debug info is called, of all things, strip.
It probably comes in various flavours (e.g. ntox86_strip, ntoppc_strip, or
whatever the nomenclature, but a commandline option to strip might specify
that).
-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
David Gibbs wrote:
By non-debug version, do you mean a version compiled with optimization
on, or do you mean a version compiled for debug, then debug information
stripped out?If you compile for debug, then strip the debug information out, then
put the stripped executable on the device, what you are trying to do
will be valid and useful. (But, the debug compiled, then stripped,
version will be bigger than the optimized version, but far smaller
than the version with full debug. At a guess, 10-50% bigger than
optimized, and about 1/5th the size of full debug.)-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
By a debug version, I mean with the -g flag. We take defaults for the
rest so some optimiztion is occuring (sh4 platform). Can you give me more
details on how I could build a debug version and strip out the debug info
and still be able to use the core with the full debug version?