From: Joel Brobecker <brobecker@adacore.com>
To: gdb@sourceware.org
Subject: gdb-7.5 status (branch?)
Date: Wed, 27 Jun 2012 14:32:00 -0000 [thread overview]
Message-ID: <20120627143138.GO2799@adacore.com> (raw)
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
next reply other threads:[~2012-06-27 14:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-27 14:32 Joel Brobecker [this message]
2012-07-02 12:14 ` Jan Kratochvil
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=20120627143138.GO2799@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).