I originally tried to solve this problem a long time ago by changing the
gdb package to depend on the selected libc debug packages. That never
did get to a state that was accepted for commit.
However, even if it did, I've come to realize that it wouldn't really
fix the problem.
Basically, core dumps do not generate valid dumps for multiple threads
when the threading debug symbols are not available. This includes
automatically generated core dumps when an application segfaults while
running (kernel generated dumps).
Two possible solutions for the problem which will ensure core dumps work
when enabled is to:
1. not strip the libc packages. Since this would mean more loaded into
memory all the time, I can understand why this may not be desirable.
2. Include the debug symbols for either all of libc or just the
specific libc debug symbols needed for a valid core dump so that core
dumps work.
a. Just have eglibc depend on eglibc-dbg and uclibc depend on
uclibc-dbg. Easy. For eglibc, this adds @35mb to a system
b. Split the required *.so.debug out from the rest of the dbg, and
have the -dbg package and base package depend on the new package. I
believe the minimal required is libpthread-*.so.debug, which for the
eglibc case adds less than 1MB to the image.
Testing would be required to ensure the right subset is selected for
2.b, but when I originally did this just adding that one debug file
caused the generated images to become fully readable.
Are either of the above possible solutions likely to get approved? I
don't mnd implementing either, but as they effectively affect every
image made, I would like to discuss before implementing one of the
solutions.
Without this change, a debug dump will have only one viewable thread.
It is not usually the crashing thread. With the required debug symbols
in place, crash dump debugging (including on a development box with the
device SDK installed) appears to function properly.
Any suggestions about what can be done that could be accepted for
inclusion into the mainline after completion would be accepted.
Is 1MB worth worrying about? I know some images that are generated are
very small, but I don't usually get things smaller than 200MB where 500K
is just noise.
Brian A. Lloyd
Brian A. Lloyd
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
