Release 2.24

Release 2.24

[Tristan Gingold]

Hello,

for the binutils 2.24 release, I plan to create the branch in Septembre, but I'd like
to wait for the git transition to create the release.

If you plan to submit big patches or if you want to submit a patch for the release,
do not hesitate to speak.

Tristan.

Re: Release 2.24

[Tristan Gingold]

On Sep 5, 2013, at 10:24 AM, Tristan Gingold <gingold@adacore.com> wrote:

> Hello,
> 
> for the binutils 2.24 release, I plan to create the branch in Septembre, but I'd like
> to wait for the git transition to create the release.
> 
> If you plan to submit big patches or if you want to submit a patch for the release,
> do not hesitate to speak.

I have just created the binutils-2_24-branch.

Tristan.

Re: Release 2.24

[Maciej W. Rozycki]

On Wed, 18 Sep 2013, Tristan Gingold wrote:

> > for the binutils 2.24 release, I plan to create the branch in Septembre, but I'd like
> > to wait for the git transition to create the release.
> > 
> > If you plan to submit big patches or if you want to submit a patch for the release,
> > do not hesitate to speak.
> 
> I have just created the binutils-2_24-branch.

 Just as a reminder, can we please coordinate so that GDB 7.7 is released 
before binutils 2.24?

 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.

 Thanks,

  Maciej

Re: Release 2.24

[Joel Brobecker]

>  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.

>  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.

-- 
Joel

Re: Release 2.24

[Maciej W. Rozycki]

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 
a backport.

 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.

  Maciej

Re: Release 2.24

[Joel Brobecker]

>  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).

Pretty much everyone who answered felt that it was more work to keep
two systems around for the duration of the branch. In GDB, branches
are active for about 6 months, which is a long time, and for Binutils,
it is 1 year, I believe. I was the only one who initially did not want
to tie the 2 together, but I changed my mind, and decided to wait
a bit, and give the full-git approach a shot.

-- 
Joel

Re: Release 2.24

[Maciej W. Rozycki]

On Wed, 18 Sep 2013, Maciej W. Rozycki wrote:

> > >  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 
> a backport.

 I see 2.24 is about to roll out, so I'll try to find some time this week 
to make the necessary adjustments for a matching GDB 7.6.2 maintenance 
release -- assuming as per your recent statement, that making 7.7 can take 
a while yet.

  Maciej

Re: Release 2.24

[Joel Brobecker]

> I see 2.24 is about to roll out, so I'll try to find some time this week 
> to make the necessary adjustments for a matching GDB 7.6.2 maintenance 
> release -- assuming as per your recent statement, that making 7.7 can take 
> a while yet.

What are your parameters? I've started working on the scripts this
weekend, and unfortunately for me, I am bursting with ideas of things
to try out - this is going to be helpful for the future, but not so
good for the present. I am planning on working on it an hour every day,
so I should have branching hopefully done soon, and then at least
pre-release creation done right after that.

To explain a bit the delay, the switch to git is more than just
changing some configuration-management commands in the script.
Git opens up the door for doing things a little differently.
For instance, I will have the scripts sends the email for me,
instead of me doing some tedious copy/pasting - this is now possible
because I don't have to be afraid of losing the connection to
sourceware while creating the branch from a repo on my laptop.
Same thing for GPG signing.

If the delay is unbearable to your platform, then we'll need to
temporary re-open the CVS, and produce an extra release from there.
Or the alternative is to produce a release by hand, but that would
take much more time, I think. Neither of these 2 options are
attractive, so it'd be better if we could wait for me to be ready.

-- 
Joel

Re: Release 2.24

[Maciej W. Rozycki]

On Mon, 18 Nov 2013, Joel Brobecker wrote:

> > I see 2.24 is about to roll out, so I'll try to find some time this week 
> > to make the necessary adjustments for a matching GDB 7.6.2 maintenance 
> > release -- assuming as per your recent statement, that making 7.7 can take 
> > a while yet.
> 
> What are your parameters? I've started working on the scripts this
> weekend, and unfortunately for me, I am bursting with ideas of things
> to try out - this is going to be helpful for the future, but not so
> good for the present. I am planning on working on it an hour every day,
> so I should have branching hopefully done soon, and then at least
> pre-release creation done right after that.
> 
> To explain a bit the delay, the switch to git is more than just
> changing some configuration-management commands in the script.
> Git opens up the door for doing things a little differently.
> For instance, I will have the scripts sends the email for me,
> instead of me doing some tedious copy/pasting - this is now possible
> because I don't have to be afraid of losing the connection to
> sourceware while creating the branch from a repo on my laptop.
> Same thing for GPG signing.
> 
> If the delay is unbearable to your platform, then we'll need to
> temporary re-open the CVS, and produce an extra release from there.
> Or the alternative is to produce a release by hand, but that would
> take much more time, I think. Neither of these 2 options are
> attractive, so it'd be better if we could wait for me to be ready.

 The 2.24 release will break debugging of MIPS16 and microMIPS binaries.  
Here are 7.6 branch testsuite results for these two ISA variations 
respectively:

		=== gdb Summary ===			=== gdb Summary ===
                                        
# of expected passes		3949	# of expected passes		3949
# of unexpected failures	627	# of unexpected failures	627
# of expected failures		13	# of expected failures		13
# of known failures		14	# of known failures		14
# of unresolved testcases	3852	# of unresolved testcases	3851
# of untested testcases		86	# of untested testcases		86
# of unsupported tests		159	# of unsupported tests		160

Please note that this is a regression compared to binutils 2.23.  With the 
change below these results turn into these:

		=== gdb Summary ===			=== gdb Summary ===
                                        
# of expected passes		15890	# of expected passes		15903
# of unexpected failures	241	# of unexpected failures	89
# of unexpected successes	1	# of unexpected successes	1
# of expected failures		28	# of expected failures		28
# of known failures		57	# of known failures		57
# of unresolved testcases	6	# of unresolved testcases	4
# of untested testcases		61	# of untested testcases		61
# of unsupported tests		193	# of unsupported tests		194

I'd prefer we had a GDB release we could refer ordinary people who compile 
from sources to if using binutils 2.24 with MIPS16 and microMIPS binaries.  
I don't care about distributions, they have the required resources and 
experience at hand to port and integrate individual changes if required. 
Referring ordinary people to the GIT master head or a snapshot is I think 
below the standards the free software community is meant to maintain, 
especially for such a core component as GDB.

 Although if you expect the delay between binutils 2.24 and GDB 7.7 to 
stay within a couple weeks, e.g. if you think you'll be able to roll the 
latter out by say mid December, then I think this will be acceptable and 
wasting your time you could spend on 7.7 to make this extra release to 
satisfy early birds unjustified.  I could also use that time to dust off 
and resubmit the two outstanding MIPS16/microMIPS changes I already 
offered and whose review (of the core non-MIPS parts) went nowhere.

 WDYT?

2013-11-21  Maciej W. Rozycki  <macro@codesourcery.com>
            Paul Brook  <paul@codesourcery.com>

	bfd/
	* elfxx-mips.h (_bfd_mips_elf_get_synthetic_symtab): New
	prototype.
	* elf32-mips.c (elf_backend_plt_sym_val): Remove macro.
	(bfd_elf32_get_synthetic_symtab): New macro.
	* elfxx-mips.c (micromips_o32_exec_plt0_entry): New variable.
	(micromips_insn32_o32_exec_plt0_entry): Likewise.
	(mips16_o32_exec_plt_entry): Likewise.
	(micromips_o32_exec_plt_entry): Likewise.
	(micromips_insn32_o32_exec_plt_entry): Likewise.
	(_bfd_mips_elf_get_synthetic_symtab): New
	function.

	gdb/
	* mips-tdep.c (mips_elf_make_msymbol_special): Handle MIPS16 and
	microMIPS synthetic symbols.

	opcodes/
	* mips-dis.c (is_mips16_plt_tail): New function.
	(print_insn_mips16): Handle MIPS16 PLT entry's GOT slot address
	word.
	(is_compressed_mode_p): Handle MIPS16/microMIPS PLT entries.

  Maciej

binutils-umips16-plt-stubs.diff
Index: gdb-fsf-7.6-quilt/bfd/elf32-mips.c
===================================================================
--- gdb-fsf-7.6-quilt.orig/bfd/elf32-mips.c	2013-11-21 03:11:06.147967511 +0000
+++ gdb-fsf-7.6-quilt/bfd/elf32-mips.c	2013-11-21 03:11:13.148736118 +0000
@@ -2344,7 +2344,6 @@ static const struct ecoff_debug_swap mip
 #define elf_backend_default_use_rela_p	0
 #define elf_backend_sign_extend_vma	TRUE
 #define elf_backend_plt_readonly	1
-#define elf_backend_plt_sym_val		_bfd_mips_elf_plt_sym_val
 
 #define elf_backend_discard_info	_bfd_mips_elf_discard_info
 #define elf_backend_ignore_discarded_relocs \
@@ -2356,6 +2355,7 @@ static const struct ecoff_debug_swap mip
 					mips_elf_is_local_label_name
 #define bfd_elf32_bfd_is_target_special_symbol \
 					_bfd_mips_elf_is_target_special_symbol
+#define bfd_elf32_get_synthetic_symtab	_bfd_mips_elf_get_synthetic_symtab
 #define bfd_elf32_find_nearest_line	_bfd_mips_elf_find_nearest_line
 #define bfd_elf32_find_inliner_info	_bfd_mips_elf_find_inliner_info
 #define bfd_elf32_new_section_hook	_bfd_mips_elf_new_section_hook
@@ -2483,7 +2483,6 @@ mips_vxworks_final_write_processing (bfd
 #define elf_backend_default_use_rela_p		1
 #undef elf_backend_got_header_size
 #define elf_backend_got_header_size		(4 * 3)
-#undef elf_backend_plt_sym_val
 
 #undef elf_backend_finish_dynamic_symbol
 #define elf_backend_finish_dynamic_symbol \
@@ -2509,4 +2508,6 @@ mips_vxworks_final_write_processing (bfd
 #undef elf_backend_symbol_processing
 /* NOTE: elf_backend_rela_normal is not defined for MIPS.  */
 
+#undef bfd_elf32_get_synthetic_symtab
+
 #include "elf32-target.h"
Index: gdb-fsf-7.6-quilt/bfd/elfxx-mips.c
===================================================================
--- gdb-fsf-7.6-quilt.orig/bfd/elfxx-mips.c	2013-11-21 03:11:06.147967511 +0000
+++ gdb-fsf-7.6-quilt/bfd/elfxx-mips.c	2013-11-21 17:44:05.928757474 +0000
@@ -969,7 +969,40 @@ static const bfd_vma mips_n64_exec_plt0_
   0x2718fffe	/* subu $24, $24, 2					*/
 };
 
-/* The format of subsequent PLT entries.  */
+/* The format of the microMIPS first PLT entry in an O32 executable.
+   We rely on v0 ($2) rather than t8 ($24) to contain the address
+   of the GOTPLT entry handled, so this stub may only be used when
+   all the subsequent PLT entries are microMIPS code too.
+
+   The trailing NOP is for alignment and correct disassembly only.  */
+static const bfd_vma micromips_o32_exec_plt0_entry[] =
+{
+  0x7980, 0x0000,	/* addiupc $3, (&GOTPLT[0]) - .			*/
+  0xff23, 0x0000,	/* lw $25, 0($3)				*/
+  0x0535,		/* subu $2, $2, $3				*/
+  0x2525,		/* srl $2, $2, 2				*/
+  0x3302, 0xfffe,	/* subu $24, $2, 2				*/
+  0x0dff,		/* move $15, $31				*/
+  0x45f9,		/* jalrs $25					*/
+  0x0f83,		/* move $28, $3					*/
+  0x0c00		/* nop						*/
+};
+
+/* The format of the microMIPS first PLT entry in an O32 executable
+   in the insn32 mode.  */
+static const bfd_vma micromips_insn32_o32_exec_plt0_entry[] =
+{
+  0x41bc, 0x0000,	/* lui $28, %hi(&GOTPLT[0])			*/
+  0xff3c, 0x0000,	/* lw $25, %lo(&GOTPLT[0])($28)			*/
+  0x339c, 0x0000,	/* addiu $28, $28, %lo(&GOTPLT[0])		*/
+  0x0398, 0xc1d0,	/* subu $24, $24, $28				*/
+  0x001f, 0x7950,	/* move $15, $31				*/
+  0x0318, 0x1040,	/* srl $24, $24, 2				*/
+  0x03f9, 0x0f3c,	/* jalr $25					*/
+  0x3318, 0xfffe	/* subu $24, $24, 2				*/
+};
+
+/* The format of subsequent standard PLT entries.  */
 static const bfd_vma mips_exec_plt_entry[] =
 {
   0x3c0f0000,	/* lui $15, %hi(.got.plt entry)			*/
@@ -978,6 +1011,39 @@ static const bfd_vma mips_exec_plt_entry
   0x03200008	/* jr $25					*/
 };
 
+/* The format of subsequent MIPS16 o32 PLT entries.  We use v0 ($2)
+   and v1 ($3) as temporaries because t8 ($24) and t9 ($25) are not
+   directly addressable.  */
+static const bfd_vma mips16_o32_exec_plt_entry[] =
+{
+  0xb203,		/* lw $2, 12($pc)			*/
+  0x9a60,		/* lw $3, 0($2)				*/
+  0x651a,		/* move $24, $2				*/
+  0xeb00,		/* jr $3				*/
+  0x653b,		/* move $25, $3				*/
+  0x6500,		/* nop					*/
+  0x0000, 0x0000	/* .word (.got.plt entry)		*/
+};
+
+/* The format of subsequent microMIPS o32 PLT entries.  We use v0 ($2)
+   as a temporary because t8 ($24) is not addressable with ADDIUPC.  */
+static const bfd_vma micromips_o32_exec_plt_entry[] =
+{
+  0x7900, 0x0000,	/* addiupc $2, (.got.plt entry) - .	*/
+  0xff22, 0x0000,	/* lw $25, 0($2)			*/
+  0x4599,		/* jr $25				*/
+  0x0f02		/* move $24, $2				*/
+};
+
+/* The format of subsequent microMIPS o32 PLT entries in the insn32 mode.  */
+static const bfd_vma micromips_insn32_o32_exec_plt_entry[] =
+{
+  0x41af, 0x0000,	/* lui $15, %hi(.got.plt entry)		*/
+  0xff2f, 0x0000,	/* lw $25, %lo(.got.plt entry)($15)	*/
+  0x0019, 0x0f3c,	/* jr $25				*/
+  0x330f, 0x0000	/* addiu $24, $15, %lo(.got.plt entry)	*/
+};
+
 /* The format of the first PLT entry in a VxWorks executable.  */
 static const bfd_vma mips_vxworks_exec_plt0_entry[] =
 {
@@ -14347,6 +14413,246 @@ _bfd_mips_elf_plt_sym_val (bfd_vma i, co
 	  + i * 4 * ARRAY_SIZE (mips_exec_plt_entry));
 }
 
+/* Build a table of synthetic symbols to represent the PLT.  As with MIPS16
+   and microMIPS PLT slots we may have a many-to-one mapping between .plt
+   and .got.plt and also the slots may be of a different size each we walk
+   the PLT manually fetching instructions and matching them against known
+   patterns.  To make things easier standard MIPS slots, if any, always come
+   first.  As we don't create proper ELF symbols we use the UDATA.I member
+   of ASYMBOL to carry ISA annotation.  The encoding used is the same as
+   with the ST_OTHER member of the ELF symbol.  */
+
+long
+_bfd_mips_elf_get_synthetic_symtab (bfd *abfd,
+				    long symcount ATTRIBUTE_UNUSED,
+				    asymbol **syms ATTRIBUTE_UNUSED,
+				    long dynsymcount, asymbol **dynsyms,
+				    asymbol **ret)
+{
+  static const char pltname[] = "_PROCEDURE_LINKAGE_TABLE_";
+  static const char microsuffix[] = "@micromipsplt";
+  static const char m16suffix[] = "@mips16plt";
+  static const char mipssuffix[] = "@plt";
+
+  bfd_boolean (*slurp_relocs) (bfd *, asection *, asymbol **, bfd_boolean);
+  const struct elf_backend_data *bed = get_elf_backend_data (abfd);
+  bfd_boolean micromips_p = MICROMIPS_P (abfd);
+  Elf_Internal_Shdr *hdr;
+  bfd_byte *plt_data;
+  bfd_vma plt_offset;
+  unsigned int other;
+  bfd_vma entry_size;
+  bfd_vma plt0_size;
+  asection *relplt;
+  bfd_vma opcode;
+  asection *plt;
+  asymbol *send;
+  size_t size;
+  char *names;
+  long counti;
+  arelent *p;
+  asymbol *s;
+  char *nend;
+  long count;
+  long pi;
+  long i;
+  long n;
+
+  *ret = NULL;
+
+  if ((abfd->flags & (DYNAMIC | EXEC_P)) == 0 || dynsymcount <= 0)
+    return 0;
+
+  relplt = bfd_get_section_by_name (abfd, ".rel.plt");
+  if (relplt == NULL)
+    return 0;
+
+  hdr = &elf_section_data (relplt)->this_hdr;
+  if (hdr->sh_link != elf_dynsymtab (abfd) || hdr->sh_type != SHT_REL)
+    return 0;
+
+  plt = bfd_get_section_by_name (abfd, ".plt");
+  if (plt == NULL)
+    return 0;
+
+  slurp_relocs = get_elf_backend_data (abfd)->s->slurp_reloc_table;
+  if (!(*slurp_relocs) (abfd, relplt, dynsyms, TRUE))
+    return -1;
+  p = relplt->relocation;
+
+  /* Calculating the exact amount of space required for symbols would
+     require two passes over the PLT, so just pessimise assuming two
+     PLT slots per relocation.  */
+  count = relplt->size / hdr->sh_entsize;
+  counti = count * bed->s->int_rels_per_ext_rel;
+  size = 2 * count * sizeof (asymbol);
+  size += count * (sizeof (mipssuffix) +
+		   (micromips_p ? sizeof (microsuffix) : sizeof (m16suffix)));
+  for (pi = 0; pi < counti; pi += bed->s->int_rels_per_ext_rel)
+    size += 2 * strlen ((*p[pi].sym_ptr_ptr)->name);
+
+  /* Add the size of "_PROCEDURE_LINKAGE_TABLE_" too.  */
+  size += sizeof (asymbol) + sizeof (pltname);
+
+  if (!bfd_malloc_and_get_section (abfd, plt, &plt_data))
+    return -1;
+
+  if (plt->size < 16)
+    return -1;
+
+  s = *ret = bfd_malloc (size);
+  if (s == NULL)
+    return -1;
+  send = s + 2 * count + 1;
+
+  names = (char *) send;
+  nend = (char *) s + size;
+  n = 0;
+
+  opcode = bfd_get_micromips_32 (abfd, plt_data + 12);
+  if (opcode == 0x3302fffe)
+    {
+      if (!micromips_p)
+	return -1;
+      plt0_size = 2 * ARRAY_SIZE (micromips_o32_exec_plt0_entry);
+      other = STO_MICROMIPS;
+    }
+  else if (opcode == 0x0398c1d0)
+    {
+      if (!micromips_p)
+	return -1;
+      plt0_size = 2 * ARRAY_SIZE (micromips_insn32_o32_exec_plt0_entry);
+      other = STO_MICROMIPS;
+    }
+  else
+    {
+      plt0_size = 4 * ARRAY_SIZE (mips_o32_exec_plt0_entry);
+      other = 0;
+    }
+
+  s->the_bfd = abfd;
+  s->flags = BSF_SYNTHETIC | BSF_FUNCTION | BSF_LOCAL;
+  s->section = plt;
+  s->value = 0;
+  s->name = names;
+  s->udata.i = other;
+  memcpy (names, pltname, sizeof (pltname));
+  names += sizeof (pltname);
+  ++s, ++n;
+
+  pi = 0;
+  for (plt_offset = plt0_size;
+       plt_offset + 8 <= plt->size && s < send;
+       plt_offset += entry_size)
+    {
+      bfd_vma gotplt_addr;
+      const char *suffix;
+      bfd_vma gotplt_hi;
+      bfd_vma gotplt_lo;
+      size_t suffixlen;
+
+      opcode = bfd_get_micromips_32 (abfd, plt_data + plt_offset + 4);
+
+      /* Check if the second word matches the expected MIPS16 instruction.  */
+      if (opcode == 0x651aeb00)
+	{
+	  if (micromips_p)
+	    return -1;
+	  /* Truncated table???  */
+	  if (plt_offset + 16 > plt->size)
+	    break;
+	  gotplt_addr = bfd_get_32 (abfd, plt_data + plt_offset + 12);
+	  entry_size = 2 * ARRAY_SIZE (mips16_o32_exec_plt_entry);
+	  suffixlen = sizeof (m16suffix);
+	  suffix = m16suffix;
+	  other = STO_MIPS16;
+	}
+      /* Likewise the expected microMIPS instruction (no insn32 mode).  */
+      else if (opcode == 0xff220000)
+	{
+	  if (!micromips_p)
+	    return -1;
+	  gotplt_hi = bfd_get_16 (abfd, plt_data + plt_offset) & 0x7f;
+	  gotplt_lo = bfd_get_16 (abfd, plt_data + plt_offset + 2) & 0xffff;
+	  gotplt_hi = ((gotplt_hi ^ 0x40) - 0x40) << 18;
+	  gotplt_lo <<= 2;
+	  gotplt_addr = gotplt_hi + gotplt_lo;
+	  gotplt_addr += ((plt->vma + plt_offset) | 3) ^ 3;
+	  entry_size = 2 * ARRAY_SIZE (micromips_o32_exec_plt_entry);
+	  suffixlen = sizeof (microsuffix);
+	  suffix = microsuffix;
+	  other = STO_MICROMIPS;
+	}
+      /* Likewise the expected microMIPS instruction (insn32 mode).  */
+      else if ((opcode & 0xffff0000) == 0xff2f0000)
+	{
+	  gotplt_hi = bfd_get_16 (abfd, plt_data + plt_offset + 2) & 0xffff;
+	  gotplt_lo = bfd_get_16 (abfd, plt_data + plt_offset + 6) & 0xffff;
+	  gotplt_hi = ((gotplt_hi ^ 0x8000) - 0x8000) << 16;
+	  gotplt_lo = (gotplt_lo ^ 0x8000) - 0x8000;
+	  gotplt_addr = gotplt_hi + gotplt_lo;
+	  entry_size = 2 * ARRAY_SIZE (micromips_insn32_o32_exec_plt_entry);
+	  suffixlen = sizeof (microsuffix);
+	  suffix = microsuffix;
+	  other = STO_MICROMIPS;
+	}
+      /* Otherwise assume standard MIPS code.  */
+      else
+	{
+	  gotplt_hi = bfd_get_32 (abfd, plt_data + plt_offset) & 0xffff;
+	  gotplt_lo = bfd_get_32 (abfd, plt_data + plt_offset + 4) & 0xffff;
+	  gotplt_hi = ((gotplt_hi ^ 0x8000) - 0x8000) << 16;
+	  gotplt_lo = (gotplt_lo ^ 0x8000) - 0x8000;
+	  gotplt_addr = gotplt_hi + gotplt_lo;
+	  entry_size = 4 * ARRAY_SIZE (mips_exec_plt_entry);
+	  suffixlen = sizeof (mipssuffix);
+	  suffix = mipssuffix;
+	  other = 0;
+	}
+      /* Truncated table???  */
+      if (plt_offset + entry_size > plt->size)
+	break;
+
+      for (i = 0;
+	   i < count && p[pi].address != gotplt_addr;
+	   i++, pi = (pi + bed->s->int_rels_per_ext_rel) % counti);
+
+      if (i < count)
+	{
+	  size_t namelen;
+	  size_t len;
+
+	  *s = **p[pi].sym_ptr_ptr;
+	  /* Undefined syms won't have BSF_LOCAL or BSF_GLOBAL set.  Since
+	     we are defining a symbol, ensure one of them is set.  */
+	  if ((s->flags & BSF_LOCAL) == 0)
+	    s->flags |= BSF_GLOBAL;
+	  s->flags |= BSF_SYNTHETIC;
+	  s->section = plt;
+	  s->value = plt_offset;
+	  s->name = names;
+	  s->udata.i = other;
+
+	  len = strlen ((*p[pi].sym_ptr_ptr)->name);
+	  namelen = len + suffixlen;
+	  if (names + namelen > nend)
+	    break;
+
+	  memcpy (names, (*p[pi].sym_ptr_ptr)->name, len);
+	  names += len;
+	  memcpy (names, suffix, suffixlen);
+	  names += suffixlen;
+
+	  ++s, ++n;
+	  pi = (pi + bed->s->int_rels_per_ext_rel) % counti;
+	}
+    }
+
+  free (plt_data);
+
+  return n;
+}
+
 void
 _bfd_mips_post_process_headers (bfd *abfd, struct bfd_link_info *link_info)
 {
Index: gdb-fsf-7.6-quilt/bfd/elfxx-mips.h
===================================================================
--- gdb-fsf-7.6-quilt.orig/bfd/elfxx-mips.h	2013-11-21 03:11:06.147967511 +0000
+++ gdb-fsf-7.6-quilt/bfd/elfxx-mips.h	2013-11-21 03:11:13.148736118 +0000
@@ -152,6 +152,8 @@ extern bfd_boolean _bfd_mips_elf_init_st
    asection *(*) (const char *, asection *, asection *));
 extern bfd_vma _bfd_mips_elf_plt_sym_val
   (bfd_vma, const asection *, const arelent *rel);
+extern long _bfd_mips_elf_get_synthetic_symtab
+  (bfd *, long, asymbol **, long, asymbol **, asymbol **);
 extern void _bfd_mips_post_process_headers
   (bfd *abfd, struct bfd_link_info *link_info);
 
Index: gdb-fsf-7.6-quilt/gdb/mips-tdep.c
===================================================================
--- gdb-fsf-7.6-quilt.orig/gdb/mips-tdep.c	2013-11-21 03:11:06.147967511 +0000
+++ gdb-fsf-7.6-quilt/gdb/mips-tdep.c	2013-11-21 17:39:39.367812441 +0000
@@ -343,8 +343,9 @@ make_compact_addr (CORE_ADDR addr)
    "special", i.e. refers to a MIPS16 or microMIPS function, and sets
    one of the "special" bits in a minimal symbol to mark it accordingly.
    The test checks an ELF-private flag that is valid for true function
-   symbols only; in particular synthetic symbols such as for PLT stubs
-   have no ELF-private part at all.
+   symbols only; for synthetic symbols such as for PLT stubs that have
+   no ELF-private part at all the MIPS BFD backend arranges for this
+   information to be carried in the asymbol's udata field instead.
 
    msymbol_is_mips16 and msymbol_is_micromips test the "special" bit
    in a minimal symbol.  */
@@ -353,13 +354,18 @@ static void
 mips_elf_make_msymbol_special (asymbol * sym, struct minimal_symbol *msym)
 {
   elf_symbol_type *elfsym = (elf_symbol_type *) sym;
+  unsigned char st_other;
 
-  if ((sym->flags & BSF_SYNTHETIC) != 0)
+  if ((sym->flags & BSF_SYNTHETIC) == 0)
+    st_other = elfsym->internal_elf_sym.st_other;
+  else if ((sym->flags & BSF_FUNCTION) != 0)
+    st_other = sym->udata.i;
+  else
     return;
 
-  if (ELF_ST_IS_MICROMIPS (elfsym->internal_elf_sym.st_other))
+  if (ELF_ST_IS_MICROMIPS (st_other))
     MSYMBOL_TARGET_FLAG_2 (msym) = 1;
-  else if (ELF_ST_IS_MIPS16 (elfsym->internal_elf_sym.st_other))
+  else if (ELF_ST_IS_MIPS16 (st_other))
     MSYMBOL_TARGET_FLAG_1 (msym) = 1;
 }
 
Index: gdb-fsf-7.6-quilt/opcodes/mips-dis.c
===================================================================
--- gdb-fsf-7.6-quilt.orig/opcodes/mips-dis.c	2013-11-21 03:11:06.147967511 +0000
+++ gdb-fsf-7.6-quilt/opcodes/mips-dis.c	2013-11-21 03:11:13.148736118 +0000
@@ -2033,6 +2033,23 @@ print_mips16_insn_arg (char type,
     }
 }
 
+
+/* Check if the given address is the last word of a MIPS16 PLT entry.
+   This word is data and depending on the value it may interfere with
+   disassembly of further PLT entries.  We make use of the fact PLT
+   symbols are marked BSF_SYNTHETIC.  */
+static bfd_boolean
+is_mips16_plt_tail (struct disassemble_info *info, bfd_vma addr)
+{
+  if (info->symbols
+      && info->symbols[0]
+      && (info->symbols[0]->flags & BSF_SYNTHETIC)
+      && addr == bfd_asymbol_value (info->symbols[0]) + 12)
+    return TRUE;
+
+  return FALSE;
+}
+
 /* Disassemble mips16 instructions.  */
 
 static int
@@ -2040,7 +2057,7 @@ print_insn_mips16 (bfd_vma memaddr, stru
 {
   const fprintf_ftype infprintf = info->fprintf_func;
   int status;
-  bfd_byte buffer[2];
+  bfd_byte buffer[4];
   int length;
   int insn;
   bfd_boolean use_extend;
@@ -2053,11 +2070,32 @@ print_insn_mips16 (bfd_vma memaddr, stru
   info->insn_info_valid = 1;
   info->branch_delay_insns = 0;
   info->data_size = 0;
-  info->insn_type = dis_nonbranch;
   info->target = 0;
   info->target2 = 0;
 
-  status = (*info->read_memory_func) (memaddr, buffer, 2, info);
+  /* Decode PLT entry's GOT slot address word.  */
+  if (is_mips16_plt_tail (info, memaddr))
+    {
+      info->insn_type = dis_noninsn;
+      status = (*info->read_memory_func) (memaddr, buffer, 4, info);
+      if (status == 0)
+	{
+	  unsigned int gotslot;
+
+	  if (info->endian == BFD_ENDIAN_BIG)
+	    gotslot = bfd_getb32 (buffer);
+	  else
+	    gotslot = bfd_getl32 (buffer);
+	  infprintf (is, ".word\t0x%x", gotslot);
+
+	  return 4;
+	}
+    }
+  else
+    {
+      info->insn_type = dis_nonbranch;
+      status = (*info->read_memory_func) (memaddr, buffer, 2, info);
+    }
   if (status != 0)
     {
       (*info->memory_error_func) (status, memaddr, info);
@@ -2931,27 +2969,26 @@ print_insn_micromips (bfd_vma memaddr, s
 static bfd_boolean
 is_compressed_mode_p (struct disassemble_info *info)
 {
-  elf_symbol_type *symbol;
-  int pos;
   int i;
+  int l;
 
-  for (i = 0; i < info->num_symbols; i++)
-    {
-      pos = info->symtab_pos + i;
-
-      if (bfd_asymbol_flavour (info->symtab[pos]) != bfd_target_elf_flavour)
-	continue;
-
-      if (info->symtab[pos]->section != info->section)
-	continue;
-
-      symbol = (elf_symbol_type *) info->symtab[pos];
-      if ((!micromips_ase
-	   && ELF_ST_IS_MIPS16 (symbol->internal_elf_sym.st_other))
-	  || (micromips_ase
-	      && ELF_ST_IS_MICROMIPS (symbol->internal_elf_sym.st_other)))
-	    return 1;
-    }
+  for (i = info->symtab_pos, l = i + info->num_symbols; i < l; i++)
+    if (((info->symtab[i])->flags & BSF_SYNTHETIC) != 0
+	&& ((!micromips_ase
+	     && ELF_ST_IS_MIPS16 ((*info->symbols)->udata.i))
+	    || (micromips_ase
+		&& ELF_ST_IS_MICROMIPS ((*info->symbols)->udata.i))))
+      return 1;
+    else if (bfd_asymbol_flavour (info->symtab[i]) == bfd_target_elf_flavour
+	      && info->symtab[i]->section == info->section)
+      {
+	elf_symbol_type *symbol = (elf_symbol_type *) info->symtab[i];
+	if ((!micromips_ase
+	     && ELF_ST_IS_MIPS16 (symbol->internal_elf_sym.st_other))
+	    || (micromips_ase
+		&& ELF_ST_IS_MICROMIPS (symbol->internal_elf_sym.st_other)))
+	  return 1;
+      }
 
   return 0;
 }

Re: Release 2.24

[Joel Brobecker]

>  Although if you expect the delay between binutils 2.24 and GDB 7.7 to 
> stay within a couple weeks, e.g. if you think you'll be able to roll the 
> latter out by say mid December,

We might be able to achieve that timeframe, but it would be very hard
for me to guaranty it. From past experience, event if we started today,
I don't remember any release cycle that took less than a month so
we are already looking at a Xmas release at best.

Here is what I propose:

   . Let's confirm the list of patches needed for the 7.6 branch
     (is there just the one in binutils?)

   . Get them approved, and pushed to the gdb_7_6-branch

   . I will need from you a small description of what this release
     is about. It will save me time and make sure I also don't say
     something incorrect if I can just copy/paste that text directly
     in the web + email announcements.

   . Once that's done, I have 2 options:

       (1) Create the new relase off the git repository, but create
           the release either manually or with the new scripts;

       (2) Push the commit to the CVS repo, and re-use the old
           scripts to make the release.

If it's only a handful of patches, my preference would be to play it
safe, and go with option (2). Pushing the patches to the CVS repo is
super easy thanks to "git cvsexportcommit", but we will need the help
of someone like Tom to temporary re-open the CVS (or, if Tom prefers,
he can cvsexportcommit the patches himself, and let us know when he
is done).

Thoughts? Tom?

-- 
Joel

Re: Release 2.24

[H.J. Lu]

On Thu, Nov 21, 2013 at 6:19 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>>  Although if you expect the delay between binutils 2.24 and GDB 7.7 to
>> stay within a couple weeks, e.g. if you think you'll be able to roll the
>> latter out by say mid December,
>
> We might be able to achieve that timeframe, but it would be very hard
> for me to guaranty it. From past experience, event if we started today,
> I don't remember any release cycle that took less than a month so
> we are already looking at a Xmas release at best.
>
> Here is what I propose:
>
>    . Let's confirm the list of patches needed for the 7.6 branch
>      (is there just the one in binutils?)
>
>    . Get them approved, and pushed to the gdb_7_6-branch
>
>    . I will need from you a small description of what this release
>      is about. It will save me time and make sure I also don't say
>      something incorrect if I can just copy/paste that text directly
>      in the web + email announcements.
>
>    . Once that's done, I have 2 options:
>
>        (1) Create the new relase off the git repository, but create
>            the release either manually or with the new scripts;
>

Create a tarball from git is very straight forward.  I put .gitattribues:

https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=.gitattributes;h=15caafcf45711c658217db66862e93e56615e31a;hb=refs/heads/hjl/linux/applied

on hjl/linux/applied branch for Linux binutils to ignore GDB files.
I created a tag for release 2.24.51.0.1:

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2fba13a799a2f6550595247ae8fe35bac016485d

Then I do

# git archive --format=tar --prefix=binutils/
hjl/linux/release/2.24.51.0.1 > binutils-2.24.41.0.1.tar

It creates a tarball for my binutils release.  You just need a different
.gitattribues for GDB,

-- 
H.J.

Re: Release 2.24

[Joel Brobecker]

> Create a tarball from git is very straight forward.  I put .gitattribues:

Thank you for the tip. It might be an interesting option, but we would
have to investigate first how much of src-release this feature covers.

For the 7.6.2 release, I want as few changes as possible, to minimize
the chances of screwup.

-- 
Joel

Re: Release 2.24

[Hans-Peter Nilsson]

On Thu, 21 Nov 2013, H.J. Lu wrote:
> On Thu, Nov 21, 2013 at 6:19 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> >        (1) Create the new relase off the git repository, but create
> >            the release either manually or with the new scripts;
> >
>
> Create a tarball from git is very straight forward.  I put .gitattribues:

For official gdb and binutils releases, please use the
src-release script, so e.g. all generated files are included.

brgds, H-P

Re: Release 2.24

[Joel Brobecker]

>    . Once that's done, I have 2 options:
> 
>        (1) Create the new relase off the git repository, but create
>            the release either manually or with the new scripts;
> 
>        (2) Push the commit to the CVS repo, and re-use the old
>            scripts to make the release.
> 
> If it's only a handful of patches, my preference would be to play it
> safe, and go with option (2). Pushing the patches to the CVS repo is
> super easy thanks to "git cvsexportcommit", but we will need the help
> of someone like Tom to temporary re-open the CVS (or, if Tom prefers,
> he can cvsexportcommit the patches himself, and let us know when he
> is done).

On second thoughts, there is fairly significant drawback in using
the CVS repository. The release process involves making some commits
as well as creating a tag, and we would want all of that in our git
repo. If we use the CVS repository, we'll have to import those changes
back from CVS into git.

I'm starting to lean towards doing everything in git, and fixup any
problem if necessary.

-- 
Joel

Re: Release 2.24

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> Thoughts? Tom?

Please consider CVS as dead.
I can provide some help for doing the release from git, if you need any.
I think src-release should work fine.  I tested it a couple of times.
I'm not sure what else there is to do.

Tom

Re: Release 2.24

[Joel Brobecker]

> Joel> Thoughts? Tom?
> 
> Please consider CVS as dead.
> I can provide some help for doing the release from git, if you need any.
> I think src-release should work fine.  I tested it a couple of times.
> I'm not sure what else there is to do.

Thanks, Tom. That settles the question. I don't think I'll need help
producing the releases.

Maciej - can you work on getting the patches approved for the branch,
and let me know when it's done? I should be able to produce a release
as early as Mon-Wed.

Thank you,
-- 
Joel

Re: Release 2.24

[Tristan Gingold]

Hello,

if I understand correctly, the patches aren't for binutils (just for gdb).  Is that correct ?

Tristan.

On Nov 21, 2013, at 8:25 PM, Maciej W. Rozycki <macro@codesourcery.com> wrote:

> On Mon, 18 Nov 2013, Joel Brobecker wrote:
> 
>>> I see 2.24 is about to roll out, so I'll try to find some time this week 
>>> to make the necessary adjustments for a matching GDB 7.6.2 maintenance 
>>> release -- assuming as per your recent statement, that making 7.7 can take 
>>> a while yet.
>> 
>> What are your parameters? I've started working on the scripts this
>> weekend, and unfortunately for me, I am bursting with ideas of things
>> to try out - this is going to be helpful for the future, but not so
>> good for the present. I am planning on working on it an hour every day,
>> so I should have branching hopefully done soon, and then at least
>> pre-release creation done right after that.
>> 
>> To explain a bit the delay, the switch to git is more than just
>> changing some configuration-management commands in the script.
>> Git opens up the door for doing things a little differently.
>> For instance, I will have the scripts sends the email for me,
>> instead of me doing some tedious copy/pasting - this is now possible
>> because I don't have to be afraid of losing the connection to
>> sourceware while creating the branch from a repo on my laptop.
>> Same thing for GPG signing.
>> 
>> If the delay is unbearable to your platform, then we'll need to
>> temporary re-open the CVS, and produce an extra release from there.
>> Or the alternative is to produce a release by hand, but that would
>> take much more time, I think. Neither of these 2 options are
>> attractive, so it'd be better if we could wait for me to be ready.
> 
> The 2.24 release will break debugging of MIPS16 and microMIPS binaries.  
> Here are 7.6 branch testsuite results for these two ISA variations 
> respectively:

Re: Release 2.24

[Joel Brobecker]

> if I understand correctly, the patches aren't for binutils (just for
> gdb).  Is that correct ?

AFAIU, that is correct. We're trying to get a GDB release out which
would be compatible with binutils 2.24, before or at the same time
you release 2.24. It looks like we would only need a handful (maybe
even just one) patch from bfd.

-- 
Joel

Re: Release 2.24

[Maciej W. Rozycki]

On Mon, 25 Nov 2013, Joel Brobecker wrote:

> > if I understand correctly, the patches aren't for binutils (just for
> > gdb).  Is that correct ?
> 
> AFAIU, that is correct. We're trying to get a GDB release out which
> would be compatible with binutils 2.24, before or at the same time
> you release 2.24. It looks like we would only need a handful (maybe
> even just one) patch from bfd.

 Correct.  These changes (there are some opcodes disassembler updates as 
well) were originally committed to binutils as two separate features, but 
I've decided there's no point in keeping them such in the GDB 7.6 
backport.  Their PLT parts are closely related (unlike their GAS and LD 
pieces).

 I'm not sure who has the authority to approve this change for GDB 7.6 
though.

  Maciej

Re: Release 2.24

[Joel Brobecker]

>  I'm not sure who has the authority to approve this change for GDB 7.6 
> though.

I suggest a quick look from the binutils maintainer who approved
the patches on HEAD.

For testing, I know you showed the spectacular improvements with
binutils 2.24. Have you tested that it doesn't change anything
when using 2.23, by any chance? Just in the interest of being extra
safe, I think that would be useful testing.

-- 
Joel

Re: Release 2.24

[Maciej W. Rozycki]

On Mon, 25 Nov 2013, Joel Brobecker wrote:

> >  I'm not sure who has the authority to approve this change for GDB 7.6 
> > though.
> 
> I suggest a quick look from the binutils maintainer who approved
> the patches on HEAD.

 Richard, can you help?

> For testing, I know you showed the spectacular improvements with
> binutils 2.24. Have you tested that it doesn't change anything
> when using 2.23, by any chance? Just in the interest of being extra
> safe, I think that would be useful testing.

 It took me a little while to set it up, but I have now did this testing.  
I ran o32 testing only, for standard MIPS, MIPS16 and microMIPS code (GCC 
multilibs).  I had to tweak compiler options used in testing so as to 
avoid producing code incompatible with standard MIPS PLT entries, 
`-fno-optimize-sibling-calls' and `-mno-jals -fno-optimize-sibling-calls' 
respectively for MIPS16 and microMIPS code.  Standard MIPS code required 
no extra options.  There were no regressions in this setup with binutils 
2.23 (the tip of binutils-2_23-branch).

  Maciej

Re: Release 2.24

[Richard Sandiford]

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> On Mon, 25 Nov 2013, Joel Brobecker wrote:
>> >  I'm not sure who has the authority to approve this change for GDB 7.6 
>> > though.
>> 
>> I suggest a quick look from the binutils maintainer who approved
>> the patches on HEAD.
>
>  Richard, can you help?

Looks good to me from what was a quick look FWIW.  As the GDB maintainer
of the relevant port I think it's really your call though.

Thanks,
Richard

Re: Release 2.24

[Joel Brobecker]

> >> I suggest a quick look from the binutils maintainer who approved
> >> the patches on HEAD.
> >
> >  Richard, can you help?
> 
> Looks good to me from what was a quick look FWIW.  As the GDB maintainer
> of the relevant port I think it's really your call though.

Thank you, Richard. Between your review and Maciej's thorough testing,
I think we have built enough confidence to put it in. This is for MIPS
only, so the worse case scenario is us making yet another corrective
release (although, 7.7 could be out shortly after 7.6.2).

Maciej, let me know when the patches are in, and I'll work on producing
the release within the next day or two.

Thank you,
-- 
Joel

Re: Release 2.24

[Maciej W. Rozycki]

On Tue, 3 Dec 2013, Joel Brobecker wrote:

> Maciej, let me know when the patches are in, and I'll work on producing
> the release within the next day or two.

 I have committed the change now, thanks for your help with getting it 
done.  You have previously requested a small description of the change for 
the purpose of making a release announcement -- please let me know if the 
commit message is enough for your needs or whether you'd prefer something 
more elaborate.

  Maciej

Re: Release 2.24

[Jeff Law]

On 09/18/2013 03:32 PM, 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.
Speaking with my Fedora/Red Hat hat on, I'd much prefer to see 
binutils-2.24 move forward independent of gdb-7.7.

Jeff

Re: Release 2.24

[Michael Matz]

Hi,

On Wed, 18 Sep 2013, Jeff Law wrote:

> On 09/18/2013 03:32 PM, 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.
> 
> Speaking with my Fedora/Red Hat hat on, I'd much prefer to see 
> binutils-2.24 move forward independent of gdb-7.7.

I have to agree with my SUSE hat :)


Ciao,
Michael.

Re: Release 2.24

[Sebastian Huber]

Hello,

now that the move to Git was successful are there plans to release Binutils 
2.24 soon?

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: Release 2.24

[Tristan Gingold]

On Nov 5, 2013, at 2:55 PM, Sebastian Huber <sebastian.huber@embedded-brains.de> wrote:

> Hello,
> 
> now that the move to Git was successful are there plans to release Binutils 2.24 soon?

I am working on it, but I also need to modify my scripts.

I plan to make a prerelease soon, and if it is good enough, I will make the release.

Tristan.

Re: Release 2.24

[Alan Modra]

On Tue, Nov 05, 2013 at 03:21:40PM +0100, Tristan Gingold wrote:
> I plan to make a prerelease soon, and if it is good enough, I will
> make the release.

Since this hasn't happened yet, I'd like to put my powerpc64 ELFv2
support onto the branch.  It's a bit risky to do so this late I know,
but the changes are almost entirely in powerpc specific code.  (The
risk I'm talking about here is that the ELFv2 changes break something
in ELFv1, not the chance that some bug exists in ELFv2 support.  The
former is small I think, the latter not so small!)

Is this OK?  We won't be asking for another release to fix some bug
that shows up in ELFv2..

These are the commits I've backported:
6c668e71eb5f8a9a3355e239738c85448adfc0e8
f9c6b9078c54ea0f018b673e2ff128e61a0aa666
71a39c98f8bedad54818c62ab2d567b0e2de546b
ee67d69a3ff0eed25d98c5e97ed6c3ede8069edc
6911b7dcb8ea17f8b811578dd4ac1ab7bb675e7b
b9e5796b0d6ebc355e4a6d06791b7366939d10f2
a078d95abc554b6c2572fcab5550591639b1c871
e8910a83af41c3dbfd00191b2720d4094f8d9532
d4a95d4999e7fe0d868254bec76722b35f064184
b4f7960d5307fe4aad2126382df78f63696e96b3
8b974ba3e8216b7f6659d2803444e0ddceaeded7
14f2c476752f3cc4bfa7baee2a5a5183aafad975
4115bfc68301edaca4dd1fd83eddeaafeda4c63c
a345bc8d317a159e3e887632d80c5a8282d34f07
52a82034ac9a288d2d8e60efa880623288b5d228
88b8e63904fda25c029deaf25d7b4e489b351470
33e44f2eb27d78f57ed83d11f04652691d896a6f
dba6fa9bce92c9f9fcca07269ac8443797bd9338
afe397ea85a3d09d936c93328a1f6bf640577cf3
14b5f73fac0e34c2fca81aa0dfbc9c7eebc922f2
e2b5892e6e75109898db1cfbda2975fa422ba762
9055360d4a69313949c3535ec065080cb814367d

-- 
Alan Modra
Australia Development Lab, IBM

Re: Release 2.24

[Tristan Gingold]

On Nov 15, 2013, at 7:35 AM, Alan Modra <amodra@gmail.com> wrote:

> On Tue, Nov 05, 2013 at 03:21:40PM +0100, Tristan Gingold wrote:
>> I plan to make a prerelease soon, and if it is good enough, I will
>> make the release.
> 
> Since this hasn't happened yet, I'd like to put my powerpc64 ELFv2
> support onto the branch.  It's a bit risky to do so this late I know,
> but the changes are almost entirely in powerpc specific code.  (The
> risk I'm talking about here is that the ELFv2 changes break something
> in ELFv1, not the chance that some bug exists in ELFv2 support.  The
> former is small I think, the latter not so small!)
> 
> Is this OK?  We won't be asking for another release to fix some bug
> that shows up in ELFv2..

Fine with me, but I let you to backport.

In case of regression, you know who to blame !

Tristan.

> 
> These are the commits I've backported:
> 6c668e71eb5f8a9a3355e239738c85448adfc0e8
> f9c6b9078c54ea0f018b673e2ff128e61a0aa666
> 71a39c98f8bedad54818c62ab2d567b0e2de546b
> ee67d69a3ff0eed25d98c5e97ed6c3ede8069edc
> 6911b7dcb8ea17f8b811578dd4ac1ab7bb675e7b
> b9e5796b0d6ebc355e4a6d06791b7366939d10f2
> a078d95abc554b6c2572fcab5550591639b1c871
> e8910a83af41c3dbfd00191b2720d4094f8d9532
> d4a95d4999e7fe0d868254bec76722b35f064184
> b4f7960d5307fe4aad2126382df78f63696e96b3
> 8b974ba3e8216b7f6659d2803444e0ddceaeded7
> 14f2c476752f3cc4bfa7baee2a5a5183aafad975
> 4115bfc68301edaca4dd1fd83eddeaafeda4c63c
> a345bc8d317a159e3e887632d80c5a8282d34f07
> 52a82034ac9a288d2d8e60efa880623288b5d228
> 88b8e63904fda25c029deaf25d7b4e489b351470
> 33e44f2eb27d78f57ed83d11f04652691d896a6f
> dba6fa9bce92c9f9fcca07269ac8443797bd9338
> afe397ea85a3d09d936c93328a1f6bf640577cf3
> 14b5f73fac0e34c2fca81aa0dfbc9c7eebc922f2
> e2b5892e6e75109898db1cfbda2975fa422ba762
> 9055360d4a69313949c3535ec065080cb814367d
> 
> -- 
> Alan Modra
> Australia Development Lab, IBM

Release 2.24 - Last call

[Tristan Gingold]

Hello,

I have just uploaded prerelease 2.23.91 for binutils 2.24 at:
ftp://sourceware.org/pub/binutils/snapshots/binutils-2.23.91.tar.bz2

4f05c9ec9f85f8b1463e6174ff525825  binutils-2.23.91.tar.bz2

This snapshot was sanity-checked for i686-pc-linux-gnu

If you have pending patches or patches to be backported, please speak now.
I plan to do the final release soon.

Tristan.

Re: Release 2.24 - Last call

[Chung-Lin Tang]

On 13/11/18 5:11 AM, Tristan Gingold wrote:
> Hello,
> 
> I have just uploaded prerelease 2.23.91 for binutils 2.24 at:
> ftp://sourceware.org/pub/binutils/snapshots/binutils-2.23.91.tar.bz2
> 
> 4f05c9ec9f85f8b1463e6174ff525825  binutils-2.23.91.tar.bz2
> 
> This snapshot was sanity-checked for i686-pc-linux-gnu
> 
> If you have pending patches or patches to be backported, please speak now.
> I plan to do the final release soon.
> 
> Tristan.
> 

I still have a patch for Nios II that I think should go in. Can you
please wait a bit? Thanks.

Chung-Lin

Re: Release 2.24 - Last call

[Chung-Lin Tang]

On 2013/11/18 下午 05:48, Chung-Lin Tang wrote:
> On 13/11/18 5:11 AM, Tristan Gingold wrote:
>> Hello,
>>
>> I have just uploaded prerelease 2.23.91 for binutils 2.24 at:
>> ftp://sourceware.org/pub/binutils/snapshots/binutils-2.23.91.tar.bz2
>>
>> 4f05c9ec9f85f8b1463e6174ff525825  binutils-2.23.91.tar.bz2
>>
>> This snapshot was sanity-checked for i686-pc-linux-gnu
>>
>> If you have pending patches or patches to be backported, please speak now.
>> I plan to do the final release soon.
>>
>> Tristan.
>>
> 
> I still have a patch for Nios II that I think should go in. Can you
> please wait a bit? Thanks.
> 
> Chung-Lin

I'm done committing here.

Thanks,
Chung-Lin

Re: Release 2.24 - Last call

[Yufeng Zhang]

Hi Tristan,

I'd like to revert

commit 7568a4e05cc35bc96e7a422a7f3a453665479197
Author: Yufeng Zhang <yufeng.zhang@arm.com>
Date:   Fri Nov 15 23:40:34 2013 +0000

and install this patch instead:

http://sourceware.org/ml/binutils/2013-11/msg00120.html

Is it too late or not?

Thanks,
Yufeng

On 11/18/13 09:11, Tristan Gingold wrote:
> Hello,
>
> I have just uploaded prerelease 2.23.91 for binutils 2.24 at:
> ftp://sourceware.org/pub/binutils/snapshots/binutils-2.23.91.tar.bz2
>
> 4f05c9ec9f85f8b1463e6174ff525825  binutils-2.23.91.tar.bz2
>
> This snapshot was sanity-checked for i686-pc-linux-gnu
>
> If you have pending patches or patches to be backported, please speak now.
> I plan to do the final release soon.
>
> Tristan.
>
>

Re: Release 2.24 - Last call

[Tristan Gingold]

On Nov 18, 2013, at 12:28 PM, Yufeng Zhang <Yufeng.Zhang@arm.com> wrote:

> Hi Tristan,
> 
> I'd like to revert
> 
> commit 7568a4e05cc35bc96e7a422a7f3a453665479197
> Author: Yufeng Zhang <yufeng.zhang@arm.com>
> Date:   Fri Nov 15 23:40:34 2013 +0000
> 
> and install this patch instead:
> 
> http://sourceware.org/ml/binutils/2013-11/msg00120.html
> 
> Is it too late or not?

Not too late, but please do it quickly.

Tristan.

> 
> Thanks,
> Yufeng
> 
> On 11/18/13 09:11, Tristan Gingold wrote:
>> Hello,
>> 
>> I have just uploaded prerelease 2.23.91 for binutils 2.24 at:
>> ftp://sourceware.org/pub/binutils/snapshots/binutils-2.23.91.tar.bz2
>> 
>> 4f05c9ec9f85f8b1463e6174ff525825  binutils-2.23.91.tar.bz2
>> 
>> This snapshot was sanity-checked for i686-pc-linux-gnu
>> 
>> If you have pending patches or patches to be backported, please speak now.
>> I plan to do the final release soon.
>> 
>> Tristan.
>> 
>> 
> 
> 

Re: Release 2.24 - Last call

[Yufeng Zhang]

On 11/18/13 12:23, Tristan Gingold wrote:
>
> On Nov 18, 2013, at 12:28 PM, Yufeng Zhang<Yufeng.Zhang@arm.com>  wrote:
>
>> Hi Tristan,
>>
>> I'd like to revert
>>
>> commit 7568a4e05cc35bc96e7a422a7f3a453665479197
>> Author: Yufeng Zhang<yufeng.zhang@arm.com>
>> Date:   Fri Nov 15 23:40:34 2013 +0000
>>
>> and install this patch instead:
>>
>> http://sourceware.org/ml/binutils/2013-11/msg00120.html
>>
>> Is it too late or not?
>
> Not too late, but please do it quickly.

Thanks.  It's done.

Yufeng

>
> Tristan.
>
>>
>> Thanks,
>> Yufeng
>>
>> On 11/18/13 09:11, Tristan Gingold wrote:
>>> Hello,
>>>
>>> I have just uploaded prerelease 2.23.91 for binutils 2.24 at:
>>> ftp://sourceware.org/pub/binutils/snapshots/binutils-2.23.91.tar.bz2
>>>
>>> 4f05c9ec9f85f8b1463e6174ff525825  binutils-2.23.91.tar.bz2
>>>
>>> This snapshot was sanity-checked for i686-pc-linux-gnu
>>>
>>> If you have pending patches or patches to be backported, please speak now.
>>> I plan to do the final release soon.
>>>
>>> Tristan.
>>>
>>>
>>
>>
>
>

Re: Release 2.24 - Last call

[H.J. Lu]

On Mon, Nov 18, 2013 at 1:11 AM, Tristan Gingold <gingold@adacore.com> wrote:
> Hello,
>
> I have just uploaded prerelease 2.23.91 for binutils 2.24 at:
> ftp://sourceware.org/pub/binutils/snapshots/binutils-2.23.91.tar.bz2
>
> 4f05c9ec9f85f8b1463e6174ff525825  binutils-2.23.91.tar.bz2
>
> This snapshot was sanity-checked for i686-pc-linux-gnu
>
> If you have pending patches or patches to be backported, please speak now.
> I plan to do the final release soon.
>
> Tristan.
>

I'd like to get

https://sourceware.org/ml/binutils/2013-11/msg00160.html

into 2.24.  Otherwise, gold in 2.24 won't be able to handle
output from gas in 2.24.

Thanks.


-- 
H.J.

Re: Release 2.24 - Last call

[Tristan Gingold]

On Nov 18, 2013, at 2:39 PM, H.J. Lu <hjl.tools@gmail.com> wrote:

> On Mon, Nov 18, 2013 at 1:11 AM, Tristan Gingold <gingold@adacore.com> wrote:
>> Hello,
>> 
>> I have just uploaded prerelease 2.23.91 for binutils 2.24 at:
>> ftp://sourceware.org/pub/binutils/snapshots/binutils-2.23.91.tar.bz2
>> 
>> 4f05c9ec9f85f8b1463e6174ff525825  binutils-2.23.91.tar.bz2
>> 
>> This snapshot was sanity-checked for i686-pc-linux-gnu
>> 
>> If you have pending patches or patches to be backported, please speak now.
>> I plan to do the final release soon.
>> 
>> Tristan.
>> 
> 
> I'd like to get
> 
> https://sourceware.org/ml/binutils/2013-11/msg00160.html
> 
> into 2.24.  Otherwise, gold in 2.24 won't be able to handle
> output from gas in 2.24.

Make sense !

Ok for the branch once committed on the trunk.

Tristan.

Re: Release 2.24 - Last call

[H.J. Lu]

On Mon, Nov 18, 2013 at 5:49 AM, Tristan Gingold <gingold@adacore.com> wrote:
>
> On Nov 18, 2013, at 2:39 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>
>> On Mon, Nov 18, 2013 at 1:11 AM, Tristan Gingold <gingold@adacore.com> wrote:
>>> Hello,
>>>
>>> I have just uploaded prerelease 2.23.91 for binutils 2.24 at:
>>> ftp://sourceware.org/pub/binutils/snapshots/binutils-2.23.91.tar.bz2
>>>
>>> 4f05c9ec9f85f8b1463e6174ff525825  binutils-2.23.91.tar.bz2
>>>
>>> This snapshot was sanity-checked for i686-pc-linux-gnu
>>>
>>> If you have pending patches or patches to be backported, please speak now.
>>> I plan to do the final release soon.
>>>
>>> Tristan.
>>>
>>
>> I'd like to get
>>
>> https://sourceware.org/ml/binutils/2013-11/msg00160.html
>>
>> into 2.24.  Otherwise, gold in 2.24 won't be able to handle
>> output from gas in 2.24.
>
> Make sense !
>
> Ok for the branch once committed on the trunk.
>

I checked it into trunk and 2.24 branch.

Thanks.

-- 
H.J.

Re: Release 2.24 - Last call

[Cory Fields]

Am I too late to request backports for determinism fixes? These are
very significant for security-minded tools like Tor, Bitcoin, etc,
where users by nature distrust the binaries in the wild. Changes
include:

5cd84a722e09f301d1e134d075e1cfa421db08d6

Also, this approved patch that is not yet applied:
https://sourceware.org/ml/binutils/2013-11/msg00179.html

Beyond that, there's one last change needed for ld that I could have
ready for review today if there's a chance of getting the above two in
as well.

Regards,
Cory

On Mon, Nov 18, 2013 at 1:02 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Nov 18, 2013 at 5:49 AM, Tristan Gingold <gingold@adacore.com> wrote:
>>
>> On Nov 18, 2013, at 2:39 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>>> On Mon, Nov 18, 2013 at 1:11 AM, Tristan Gingold <gingold@adacore.com> wrote:
>>>> Hello,
>>>>
>>>> I have just uploaded prerelease 2.23.91 for binutils 2.24 at:
>>>> ftp://sourceware.org/pub/binutils/snapshots/binutils-2.23.91.tar.bz2
>>>>
>>>> 4f05c9ec9f85f8b1463e6174ff525825  binutils-2.23.91.tar.bz2
>>>>
>>>> This snapshot was sanity-checked for i686-pc-linux-gnu
>>>>
>>>> If you have pending patches or patches to be backported, please speak now.
>>>> I plan to do the final release soon.
>>>>
>>>> Tristan.
>>>>
>>>
>>> I'd like to get
>>>
>>> https://sourceware.org/ml/binutils/2013-11/msg00160.html
>>>
>>> into 2.24.  Otherwise, gold in 2.24 won't be able to handle
>>> output from gas in 2.24.
>>
>> Make sense !
>>
>> Ok for the branch once committed on the trunk.
>>
>
> I checked it into trunk and 2.24 branch.
>
> Thanks.
>
> --
> H.J.

Re: Release 2.24 - Last call

[Tristan Gingold]

On Nov 18, 2013, at 8:33 PM, Cory Fields <cory@coryfields.com> wrote:

> Am I too late to request backports for determinism fixes? These are
> very significant for security-minded tools like Tor, Bitcoin, etc,
> where users by nature distrust the binaries in the wild. Changes
> include:
> 
> 5cd84a722e09f301d1e134d075e1cfa421db08d6
> 
> Also, this approved patch that is not yet applied:
> https://sourceware.org/ml/binutils/2013-11/msg00179.html

Ok for them.

> Beyond that, there's one last change needed for ld that I could have
> ready for review today if there's a chance of getting the above two in
> as well.

I am a little bit worried about it.  Will that be ready for this week ?

Tristan.

Re: Release 2.24 - Last call

[Cory Fields]

On Tue, Nov 19, 2013 at 4:25 AM, Tristan Gingold <gingold@adacore.com> wrote:
>
> On Nov 18, 2013, at 8:33 PM, Cory Fields <cory@coryfields.com> wrote:
>
>> Am I too late to request backports for determinism fixes? These are
>> very significant for security-minded tools like Tor, Bitcoin, etc,
>> where users by nature distrust the binaries in the wild. Changes
>> include:
>>
>> 5cd84a722e09f301d1e134d075e1cfa421db08d6
>>
>> Also, this approved patch that is not yet applied:
>> https://sourceware.org/ml/binutils/2013-11/msg00179.html
>
> Ok for them.
>

Great, thanks.

>> Beyond that, there's one last change needed for ld that I could have
>> ready for review today if there's a chance of getting the above two in
>> as well.
>
> I am a little bit worried about it.  Will that be ready for this week ?
>
> Tristan.
>

I should hope so. I'm awaiting a bit of input from Nick. I can have a
patch ready for review soon-after.

Regards,
Cory