suggestion: release GDB 6.8.1

suggestion: release GDB 6.8.1

[Thiago Jung Bauermann]

Hi everybody,

Since the next big GDB release will take a while yet in order to wait
for the current developments to settle down, I'd like to suggest making
a point release to get some patches out there earlier.

In particular, Ulrich Weigand fixed issues with versioned symbols and
plt entries in ppc64-linux which fix a number of failures in the GDB
testsuite and are also easy enough to stumble upon in practice.

Up until now I have the following list of patches which I'd like to
include:

- Re: [RFA] Fix GDB's handling of the inferior controlling terminal.
  http://sourceware.org/ml/gdb-patches/2008-03/msg00126.html

- Fix several PowerPC64 ABI issues
  http://sourceware.org/ml/gdb-patches/2008-05/msg00118.html

- Handle minimal symbols pointing to function descriptors:
  http://sourceware.org/ml/gdb-patches/2008-05/msg00120.html

  This one actually depends on a patch which introduces
  get_objfile_arch, which in turn depends on a patch reworking DWARF-2
  address size handling. Instead of pulling all that, it's easier to
  just replace all calls to get_objfile_arch by current_gdbarch.

- Fix stepping into solib function on powerpc64-linux
  http://sourceware.org/ml/gdb-patches/2008-05/msg00451.html

Sérgio already backported the patches above to GDB 6.8 and ran the
testsuite on ppc-linux and ppc64-linux, finding no regressions.

For ppc64, the following improvement is seen:

                === gdb Summary ===

-# of expected passes           12042
-# of unexpected failures       150
+# of expected passes           12080
+# of unexpected failures       112
 # of unexpected successes      2
 # of expected failures         44
 # of known failures            39
 # of untested testcases        10
 # of unsupported tests         41

Which is nothing to sneeze at. However, current CVS HEAD on the same
machine gives:

                === gdb Summary ===

# of expected passes            12641
# of unexpected failures        73
# of expected failures          41
# of known failures             61
# of unresolved testcases       2
# of untested testcases         10
# of unsupported tests          43

So I guess there are a few other patches worth including in the branch.
I'll see if I can spot them.
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

Re: suggestion: release GDB 6.8.1

[Joel Brobecker]

> Since the next big GDB release will take a while yet in order to wait
> for the current developments to settle down, I'd like to suggest making
> a point release to get some patches out there earlier.

I don't mind making a point release, if you get the patches in the
branch.  It would be nice if the new release brought a little more
than the few patches you highlighted, though. I usually try to keep
an eye for patches that might qualify, but few caught my attention
since 6.8...

-- 
Joel

Re: suggestion: release GDB 6.8.1

[Doug Evans]

On Wed, Aug 6, 2008 at 3:48 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Since the next big GDB release will take a while yet in order to wait
>> for the current developments to settle down, I'd like to suggest making
>> a point release to get some patches out there earlier.
>
> I don't mind making a point release, if you get the patches in the
> branch.  It would be nice if the new release brought a little more
> than the few patches you highlighted, though. I usually try to keep
> an eye for patches that might qualify, but few caught my attention
> since 6.8...

Since you're asking ...

How should one interpret "a little more than the few patches"?  Are
you looking for bug fixes only, or does the scope include modest new
features (e.g. the "find" command) ?

Re: suggestion: release GDB 6.8.1

[Joel Brobecker]

> How should one interpret "a little more than the few patches"?  Are
> you looking for bug fixes only, or does the scope include modest new
> features (e.g. the "find" command) ?

Normally, we should only accept  bug fixes that are absolutely safe or
otherwise critical I would say.  Self-contained features that do not
endanger the rest of the code might be acceptable for the branch, but
we usually freeze new features on branches.

Regarding the "find" patch, I need to look at it again. I'm pretty
reluctant to introduce a new feature on a branch on principle, but
if you convince the other maintainers, I won't object.

-- 
Joel