This is the mail archive of the
mailing list for the binutils project.
Re: Release 2.24
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Tristan Gingold <gingold at adacore dot com>, Richard Sandiford <rdsandiford at googlemail dot com>, <binutils at sourceware dot org>, <gdb-patches at sourceware dot org>
- Date: Wed, 18 Sep 2013 23:26:40 +0100
- Subject: Re: Release 2.24
- Authentication-results: sourceware.org; auth=none
- References: <2741C968-721F-46E9-A2BA-E4B0F64C444B at adacore dot com> <BB32BE2A-A3CC-494C-9FB2-CFD322F49EA3 at adacore dot com> <alpine dot DEB dot 1 dot 10 dot 1309182134580 dot 4379 at tp dot orcam dot me dot uk> <20130918213245 dot GO3132 at adacore dot com>
On Wed, 18 Sep 2013, Joel Brobecker wrote:
> > Just as a reminder, can we please coordinate so that GDB 7.7 is released
> > before binutils 2.24?
> It's fine with GDB of course if the Binutils projects wants to wait
> for the GDB 7.7 release, but my guess is that we are quite a ways
> away from it: We need the git transition to be done first, then
> we need to make the branch and stabilize it towards a release state.
I reckon the original plan was to make the steps in the reverse order so
that there's no pressure from outstanding releases to get the GIT tree in
order, which I found reasonable -- what was the rationale behind changing
the plan? It has somehow escaped me (a list archive reference will do).
> > On the MIPS target we've switched PLT formats produced by LD for MIPS16
> > and microMIPS binaries and for correct frame unwinding GDB has to
> > understand them. Otherwise it'll fail in odd ways, e.g. when stepping
> > over a function called via PLT. Of course all code required is there in
> > our shared repository, it's just a matter of making the releases in the
> > right order so that ordinary developers have a version of GDB to upgrade
> > to available if needed.
> Can you patch gdb-7.6 to understand the new format as well as
> the old one with a patch that could be deemed safe? Perhaps it would
> make sense to make a 7.6.2 release just for MIPS.
That sounds like a plan, thanks, and should be doable with a reasonable
effort -- the changes really needed by GDB are the addition of
_bfd_mips_elf_get_synthetic_symtab to bfd/elfxx-mips.c, its wiring in
bfd/elf32-mips.c, and then small self-contained pieces in opcodes/ and of
course gdb/. I'll have a look at it and let you know when I'm ready with
BTW, please note that the old format remains supported and produced for
standard MIPS and, in some cases, mixed-mode binaries, so it's not like
it's going away or something.