[OE-core] [PATCH 1/1] Enhancements to allow core file debugging to work properly from devices

[Brian Lloyd]

The patch adds gcore when gcore package is added to the install packages
list for an image.  That gives a simple core generation wrapper around
gcc, which might simplify your testing.
It appears -dev includes -dbg, and the file I want is in -dbg, so I can
submit a new patch limiting to only -dbg just fine.  The -dev for
glib-thread-db isn't very big so I didn't catch the extra files not
really needed.  I have used this in an image that was still 50mbish in
size.  Since before I made the patch, I made a hybrid system by manually
placing the one debug symbols file onto the disk, and once the symbols
file was in place cores generated became readable, and before that the
cores were unreadable, I have strong evidence only the debug symbols are
needed.

gcore PID
is the syntax to create a core dump using the helper script.  You can
also use gdb directly to debug or generate a core dump.  If the program
is multi-threaded, without the above patch a core loaded into a system
that has full -dev config (either an SDK or larger system image for
development) could not properly read the core dump.  With the above
patch or adding the debug symbol file manually, the core could be read
by the debugger.  Since I am building a i686 based system, I am able to
run my images on a PC in a sysroot, which made my testing easier.  I
also tried via a standard end system type disk on a device and a
development environment loaded on the device, and got the same results.


Brian


On Thu, 2013-10-31 at 08:54 -0500, Mark Hatle wrote:

> On 10/31/13, 1:54 AM, blloyd wrote:
> > gdb includes a script to make generating core files trivial.  Add a package to allow inclusion of this script in images.  GDB also requires symbols that are usually stripped from the threads library to properly generate a core dump.  Therefore, ensure when gdb is installed the necessary debug file is also present so gdb is fully functional.
> >
> > Signed-off-by: blloyd <blloyd at familyhonor.net>
> > ---
> >   meta/recipes-devtools/gdb/gdb-common.inc | 12 +++++++-----
> >   meta/recipes-devtools/gdb/gdb.inc        |  9 ++++++++-
> >   2 files changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/meta/recipes-devtools/gdb/gdb-common.inc b/meta/recipes-devtools/gdb/gdb-common.inc
> > index 6954954..02eef85 100644
> > --- a/meta/recipes-devtools/gdb/gdb-common.inc
> > +++ b/meta/recipes-devtools/gdb/gdb-common.inc
> > @@ -61,8 +61,10 @@ do_install_append() {
> >   	rm -rf ${D}${datadir}/locale
> >   }
> >
> > -RRECOMMENDS_gdb_append_linux = " glibc-thread-db "
> > -RRECOMMENDS_gdb_append_linux-gnueabi = " glibc-thread-db "
> > -RRECOMMENDS_gdbserver_append_linux = " glibc-thread-db "
> > -RRECOMMENDS_gdbserver_append_linux-gnueabi = " glibc-thread-db "
> > -
> > +# Unfortunately, for gdb multi-threading to function reliably it must have the eglibc debug symbols
> > +# which are a part of the eglibc-dev package.  So we have added a dependency on that here.
> > +RRECOMMENDS_gdb_append_linux = " glibc-thread-db eglibc-dev "
> > +RRECOMMENDS_gdb_append_linux-gnueabi = " glibc-thread-db eglibc-dev "
> > +RRECOMMENDS_gdbserver_append_linux = " glibc-thread-db eglibc-dev "
> > +RRECOMMENDS_gdbserver_append_linux-gnueabi = " glibc-thread-db eglibc-dev "
> > +RDEPENDS_gcore_append = " gdb "
> 
> The debug symbols should be in the -dbg package, not the -dev package.  The -dev 
> package should simply be symlinks and special development only components, while 
> the -dbg is the split symbols.
> 
> With the eglibc-dbg installed onto the gdb environment, it should be possible to 
> have all necessary symbols to do whatever processing is required.  If this 
> doesn't work, it likely needs to be investigated.  (If something in -dev is 
> required, likely there is another bug somewhere else that needs to be fixed in 
> the packaging of eglibc.)
> 
> Do you have steps on using this code (a test command perhaps?).  I've recently 
> been asked to investigate some issues with debugging when using libpthread, and 
> I suspect the problem may be over zealous stripping of the libpthread.so on the 
> target.  But I still haven't finished my evaluation yet.
> 
> --Mark
> 
> > diff --git a/meta/recipes-devtools/gdb/gdb.inc b/meta/recipes-devtools/gdb/gdb.inc
> > index 3321a24..9bf0e86 100644
> > --- a/meta/recipes-devtools/gdb/gdb.inc
> > +++ b/meta/recipes-devtools/gdb/gdb.inc
> > @@ -10,5 +10,12 @@ SRC_URI += "file://kill_arm_map_symbols.patch \
> >   #export CFLAGS_append=" -L${STAGING_LIBDIR}"
> >
> >   # cross-canadian must not see this
> > -PACKAGES =+ "gdbserver"
> > +PACKAGES =+ "gdbserver gcore"
> >   FILES_gdbserver = "${bindir}/gdbserver"
> > +FILES_gcore = "${bindir}/gcore"
> > +
> > +do_install_append() {
> > +  # When trying to find what went wrong with a program, a core dump can be very helpful
> > +  # Go ahead and make it easier to get one when we have gdb on the system
> > +  install -m 0755 ${S}/gdb/gdb_gcore.sh ${D}${bindir}/gcore
> > +}
> >
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20131031/874de6b3/attachment-0002.html>