touch-packages team mailing list archive

[Matthias Klose <doko@xxxxxxxxxx>]

this was ppc64el only, now fixed in utopic. I really would like to see
the utopic version in trusty, re-adding the linaro changes and the
updates of the 7.7.1 release, as documented at
https://sourceware.org/gdb/

This is a minor corrective release over GDB 7.7, fixing the following
issues:

PR win32/14018 (pc register not available error on Windows)
PR python/16547 (GDB crashing on gdb.python/py-linetable.exp)
PR build/16550 (64-bit GDB doesn't build on Solaris)
PR gdb/16626 (auto-load regression: gdb uses wrong file to test safeness)
PR breakpoints/16292 (GDB oversteps a range in some cases.)
PR gdb/16575 (stale breakpoint instructions in the code cache)
PR gdb/16696 (AIX 32-bit cores, high section addresses)
PR gdb/16721 (Erroneous backtrace on AVR)
PR gdb/16832 (Erroneous backtrace on avrxmega architectures)
PR build/16873 (GDB 7.7 does not build with GCC 4.9)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  Triaged
Status in “gdb” source package in Trusty:
  Triaged
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