This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

update on the gdb-7.0 branch/release


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]