Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb@sourceware.org
Subject: update on the gdb-7.0 branch/release
Date: Tue, 05 May 2009 17:35:00 -0000	[thread overview]
Message-ID: <20090505173540.GB894@adacore.com> (raw)

Hello everyone,

The targeted branch time (2009-05-08) is fast approaching, and there are
still lots of items on the list.  I think the following elements should
be relatively quick&easy to fix:

 (1) Assert in frame.c:get_frame_arch.
     IIRC, this assert was added to control accesses to this function,
     but is not otherwise essential for correct behavior; So worse
     case scenario, we could simply remove the assert on the branch
     while we investigate a proper fix on the HEAD.

 (2) Python pretty-printing: 1 issue left: Printing strings with
     NUL characters in them.
     Is that blocking? Or can we fix quickly?

 (3) PR/9723: gdb breakpoints silently fail on PIE binaries 
     We don't need to fix this issue, but we need to add a warning
     that PIE is not supported.

On the other hand, the following might be tricky:

 (4) PR/9711: Quadratic slowdown for "where" command. 
     This was deemed blocking for the release.

Not sure about the following two items:
   
 (5) PR/9786: Typing "info frame" immediately after connecting to a remote
     target causes an assertion error on x86 GNU/Linux (32 bit). 

 (6) Commands attached to breakpoints
     Apparently, an annoying bug.

At this point, it seems too late to think about including inlining
support in 7.0:

 (7) Inlining support:
     Has Mark removed his objection based on Daniel's answers to
     his latest remarks?

One of the issues I should mention is my availability. Unfortunately,
I don't think I'll be able to fulfill my duties until May 18. I'll
also be away 10 days starting May 28, with only sporadic email access.

Given all that, I'm not sure it's wise to try to push for a release
before the summit. What I suggest is that we try to address all the
issues above ASAP, and then branch as soon as we're satisfied.
Or perhaps, we might still want to branch on time, and then address
the issues on both head and branch. I'm OK with that. I'll delay the
pre-release pending resolution of the issues if necessary.

Thoughts?

-- 
Joel


             reply	other threads:[~2009-05-05 17:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-05 17:35 Joel Brobecker [this message]
2009-05-08 18:28 ` Tom Tromey
2009-05-08 20:51   ` Joel Brobecker
2009-05-17 20:08     ` Eli Zaretskii
2009-05-17 21:38       ` Joel Brobecker
2009-05-18  3:05         ` Eli Zaretskii
2009-05-18 15:40         ` Stan Shebs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090505173540.GB894@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox