[Bug 1233185] Re: gdb-multiarch cannot read ARM cores: "wrong size gregset struct in core file"

[Steve Langasek]

Hello Martin, or anyone else affected,

Accepted gdb into trusty-proposed. The package will build now and be
available at http://launchpad.net/ubuntu/+source/gdb/7.7-0ubuntu3.2 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: gdb (Ubuntu Trusty)
       Status: In Progress => Fix Committed

** Tags added: verification-needed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1233185

Title:
  gdb-multiarch cannot read ARM cores: "wrong size gregset struct in
  core file"

Status in “gdb” package in Ubuntu:
  In Progress
Status in “gdb” source package in Trusty:
  Fix Committed
Status in “gdb” package in Debian:
  Fix Released

Bug description:
  We are getting complaints that the Launchpad apport retracers cannot
  create proper symbolic stack traces for crashes on ARM. It seems gdb-
  multiarch does not get along with our core dumps on ARM any more.
  Reproducing the full apport-retrace environment is a bit complicated,
  so I reduced this to a very simple test case:

  Log into an ARM machine, like the Nexus G4, or porter-
  armhf.canonical.com (shedir), using "schroot -c saucy-armhf".

   1. create a core dump of bash:

       $ cd /tmp/
       $ bash -c 'ulimit -c unlimited; kill -SEGV $$'

    2. Run it with gdb:

      $ gdb --batch --ex 'file /bin/bash' --ex 'core-file core' --ex 'bt'
      Core was generated by `bash -c ulimit -c unlimited; kill -SEGV $$'.
      Program terminated with signal 11, Segmentation fault.
      #0  0x00007f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:8181
   	../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden.
      #0  0x00007f2eae349257 in kill () at ../sysdeps/unix/syscall-template.S:81
      #1  0x00000000004418a1 in kill_pid ()
      [...]

      There are not a lot of symbols as usually one doesn't have bash-
  dbgsym etc. installed, but it's clearly able to produce a stack trace.

    3. Run the same with gdb-multiarch:

       $ gdb-multiarch --batch --ex 'file /bin/bash' --ex 'core-file core' --ex 'bt'
      warning: wrong size gregset struct in core file
      Core was generated by `bash -c ulimit -c unlimited; kill -SEGV $$'.
      Program terminated with signal 11, Segmentation fault.
      warning: wrong size gregset struct in core file
      #0  <unavailable> in ?? ()
      #0  <unavailable> in ?? ()
      PC not available

  FTR, Apport uses gdb-multiarch on amd64, and --ex 'set architecture
  arm' --ex 'set gnutarget elf32-littlearm' to generate stack traces for
  ARM coredumps on x86 (using binaries/libaries/debug symbols for ARM
  that get unpacked into a temporary directory). The full invocation
  looks something like this:

    gdb-multiarch --ex 'set architecture arm' --ex 'set gnutarget
  elf32-littlearm' --ex 'set debug-file-directory /tmp/s/usr/lib/debug'
  --ex 'set solib-absolute-prefix /tmp/s' --ex 'file /tmp/s/bin/bash'
  --ex 'core-file CoreDump' --ex 'bt full' --batch

  But as gdb-multiarch does not even work on a native ARM machine for a
  native ARM core dump of the very same machine/OS, I guess it's
  something more fundamental which got broken there.

  The same test case on amd64 works fine BTW, i. e. gdb-multiarch can
  process amd64 binaries on amd64.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1233185/+subscriptions