gdb-7.5 status (branch?)

[Joel Brobecker <brobecker at adacore dot com>]

Hello everyone,

Time for a quick status update for the GDB 7.5 branch again.
I see that the list of items in our TODO list has grown :-(.

Sounds to me like the following could be checked in reasonably soon:

    # [Jan] [mingw] Fix "%lld" compilation error
    # [Jan] auto-load safe-path: Permit shell wildcards

My thoughts & questions on some of the tickets:

    # [dje] Noticeable performance degradation with large C++ apps.

        There is a work-around of compiling with -fno-debug-type-sections,
        so optional? (if yes, probably a note in the release announcement)

          http://sourceware.org/bugzilla/show_bug.cgi?id=14002

    # [dje] Performance issue with .gdb_index and large numbers of shared libs.

          Status?
          http://sourceware.org/bugzilla/show_bug.cgi?id=14125

    # [dje] Fix inconsistency in blockvector addrmap vs non-addrmap handling

          At first, it sounded like the initial patch was fine.
          But then some more developments occurred. What can we do?
          Is it sufficient to apply the initial patch, and then
          fix other problem. Or is that first patch insufficient
          or incorrect?

          http://sourceware.org/ml/gdb-patches/2012-06/msg00109.html

    # [Jan] -iex and -ix: Execute them _after_ gdbinits

      The proposal was surprisingingly controversial, but my
      understanding is that it is 3 GMs in favor versus 1 against.
      As much as I hate these situations, I think Jan should go
      ahead. It's not just a question of numbers: Jan designed
      an wrote the feature for his own needs, so I think he should
      have a stronger voice about what the feature should do.
      And since most GMs who expressed an opinion were in favor
      of the adjustment...

      http://sourceware.org/ml/gdb-patches/2012-06/msg00549.html

   # I also have a set of changes for ia64-hpux, which fix a crash
     when debugging programs that use fork. But that's not critical.
     Hopefully I'll be able to commit in time.

Based on this, should we branch, or not? Given the status on some
of the issues, I think I'll wait a few more days to get those ones
out of the way. I propose we re-evaluate again on Monday.

--
Joel