On Fri, Jun 6, 2014 at 8:58 PM, blloyd <[email protected]> wrote: > 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 work for all my debugging needs. > > Are either of the above possible solutions likely to get approved? I don't > mind 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 appreciated.
what happens if you install eglibc-thread-db ? does that solve the problem > > 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. > > -- > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
