FFE for lucid - gdb-7.1 (or gdb-7.0.90.2010xxyy)

[Matthias Klose]

Binary package hint: gdb

gdb-7.1 was branched two weeks ago, although the targeted release date did pass, it's not yet released. however the test results look encouraging. two reasons for inclusion in lucid are:

 - no need to backport more patches for ARM
 - PIE patches included upstream

NEWS file is attached to the report.

[Matthias Klose (doko)]

test packages:https://launchpad.net/~ubuntu-toolchain-r/+archive/test/+sourcepub/989814/+listing-archive-extra
PPA: https://launchpad.net/~ubuntu-toolchain-r/+archive/test/+packages

[Kees Cook (kees)]

So nice to finally have PIE support upstream! I rebased the PIE testsuite and cleaned up the series file from the RH patch cruft. Please apply the attached debdiff before uploading to the archive.

[Matthias Klose (doko)]

updated packages:
https://launchpad.net/~ubuntu-toolchain-r/+archive/test/+sourcepub/990196/+listing-archive-extra

[Dave Martin (dave-martin-arm)]

> -----Original Message-----
> From: Matthew Gretton-Dann

[...]

> After some work with NCommander on IRC yesterday afternoon we
> identified a problem with privateSnippetExecutor being marked
> CANTUNWIND.
>
> Examination of the source shows that this is a piece of
> handwritten assembly which did not have unwind directives
> added to it (source snippet available at
> http://paste.ubuntu.com/391906/. NCommander tried to add
> unwind directives to it (see http://paste.ubuntu.com/391919/
> however this did not work.

[continues below]

[From http://paste.ubuntu.com/391906/:]

> ~/chroot/karmic/src/OOO320_m12/bridges/source/cpp_uno/gcc3_linux_arm$ cat armhelper.s
> @ ARM support code for OpenOffice C++/UNO bridging
> @
> @ Written by Peter Naulls <email address hidden>
> @ Modified by Caolan McNamara <email address hidden>
> .file "armhelper.s"
> .text
> .align 4
> .global privateSnippetExecutor
> .type privateSnippetExecutor, %function
> privateSnippetExecutor:
> stmfd sp!, {r0-r3} @ follow other parameters on stack
> mov r0, ip @ r0 points to functionoffset/vtable
> mov ip, sp @ fix up the ip
> stmfd sp!, {fp,ip,lr,pc} @ 8 x 4 => stack remains 8 aligned
> sub fp, ip, #4 @ set frame pointer
>
> add r1, sp, #16 @ r1 points to this and params
> bl cpp_vtable_call(PLT)
>
> add sp, sp, #32 @ restore stack
> ldr fp, [sp, #-32] @ restore frame pointer
> ldr pc, [sp, #-24] @ return

> src/OOO320_m12/bridges# cat source/cpp_uno/gcc3_linux_arm/armhelper.s
> @ ARM support code for OpenOffice C++/UNO bridging
> @
> @ Written by Peter Naulls <email address hidden>
> @ Modified by Caolan McNamara <email address hidden>
> .file "armhelper.s"
> .text
> .align 4
> .global privateSnippetExecutor
> .type privateSnippetExecutor, %function
> privateSnippetExecutor:
> .fnstart
> .save {r0, r1, r2, r3}
> stmfd sp!, {r0-r3} @ follow other parameters on stack
> mov r0, ip @ r0 points to functionoffset/vtable
> mov ip, sp @ fix up the ip
>
> .save {fp,ip,lr,pc}
> stmfd sp!, {fp,ip,lr,pc} @ 8 x 4 => stack remains 8 aligned
> sub fp, ip, #4 @ set frame pointer
>
> add r1, sp, #16 @ r1 points to this and params
> bl cpp_vtable_call(PLT)
>
> add sp, sp, #32 @ restore stack
> ldr fp, [sp, #-32] @ restore frame pointer
> ldr pc, [sp, #-24] @ return
> .fnend

[From http://paste.ubuntu.com/391919/:]

> src/OOO320_m12/bridges# cat source/cpp_uno/gcc3_linux_arm/armhelper.s
> @ ARM support code for OpenOffice C++/UNO bridging
> @
> @ Written by Peter Naulls <email address hidden>
> @ Modified by Caolan McNamara <email address hidden>
> ...

[Dave Martin (dave-martin-arm)]

Argh, ignore that last post! (#5)

This relates to a completely different bug...

[Martin Pitt (pitti)]

The benefit/risk ratio is good for this one. It's primarily a developer tool, has an extensive test suite, and helps ARM support.

I just tested them with Apport, and there was one test case failure due to slightly changed output format (just fixed in apport trunk), but in general works fine. I also ran the pkg-create-dbgsym test suite, it passes with the new gdb.

What I would like to see is a test that 7.1 still works with valgrind and anjuta, just in case the CLI changed in a way that breaks compatibility with those.

Also, since this is currently a prerelease/svn snapshot, does upstream have a firm plan when to release the final version? We certainly want that in lucid.

[Matthias Klose (doko)]

http://sourceware.org/ml/gdb/2010-03/msg00057.html

"I would like to release gdb-7.1 in a week from now, say Tues or Wed.
That would put us roughly about a month after the branch was cut and
the pre-release got out."

should be Mar 16, or Mar 17.

[Martin Pitt (pitti)]

Thanks Matthias. Mirco agreed to testing anjuta, for the record.

[Loïc Minier (lool)]

doko pinged me on valgrind/armel WRT this bug: valgrind was just enabled on armel and is actually broken ATM; I think it relates to our thumb2 default, but I didn't have time to look into it. I think valgrind works well on the i386/amd64 arches; I'm not sure how it relates to gdb.

[Mirco Müller (macslow)]

I tried it with anjuta, compiled a small GL/cairo program of mine... started a debug-session from within anjuta... defined some breakpoints, stepped through some functions, watched some variables, observed the call stack... all worked fine.

[Matthias Klose (doko)]

thanks for the feedback; now preparing the upload

[Launchpad Janitor (janitor)]

This bug was fixed in the package gdb - 7.0.90.20100311-0ubuntu1

---------------
gdb (7.0.90.20100311-0ubuntu1) lucid; urgency=low

  [ Matthias Klose ]
  * Snapshot, taken from the 7.1 release branch. LP: #535179.
  * Adjust patches, remove obsolete patches.

  [ Kees Cook ]
  * Rebase PIE testsuite, updates patch series.
 -- Matthias Klose <email address hidden> Thu, 11 Mar 2010 17:52:58 +0100