Re: Release 2.21.1 ?

Re: Release 2.21.1 ?

[Sedat Dilek]

Hi,

while handling several breakages in linux-next kernel, it showed PR
gas/12519 (see [1]) is somehow incomplete as it gives no pointer to
the symbol name in case of an error.
"Mention symbol name in non-constant .size expression." (see [2]) as a
follow-up patch definitely helps to enlighten developer's where to dig
into occuring problems.
"Revert the last change on gas/elf/bad-size.err." (see [3]) is a fixup to [2].

It would be nice to see [2] and [3] backported to 2.21-branch.

Thanks.

Regards,
- Sedat -

[1] http://sourceware.org/git/?p=binutils.git;a=commit;h=345bbf7731af2912390e72b86807eb1b2af3e27b
[2] http://sourceware.org/git/?p=binutils.git;a=commit;h=b9521fc0be7945fc842ce1197e241a023378125d
[3] http://sourceware.org/git/?p=binutils.git;a=commit;h=cbd141bb69f791de7ea1581abe7afb34f0c61288

Re: Release 2.21.1 ?

[Tristan Gingold]

On Mar 16, 2011, at 7:44 AM, Sedat Dilek wrote:

> Hi,
> 
> while handling several breakages in linux-next kernel, it showed PR
> gas/12519 (see [1]) is somehow incomplete as it gives no pointer to
> the symbol name in case of an error.
> "Mention symbol name in non-constant .size expression." (see [2]) as a
> follow-up patch definitely helps to enlighten developer's where to dig
> into occuring problems.
> "Revert the last change on gas/elf/bad-size.err." (see [3]) is a fixup to [2].
> 
> It would be nice to see [2] and [3] backported to 2.21-branch.

Why not.

Does it make sense to generate a warning instead of an error in 2.21.1 for backward bug-compatibility ?
Alan, what's your opinion ?

Tristan.

Re: Release 2.21.1 ?

[Sedat Dilek]

On Wed, Mar 16, 2011 at 9:50 AM, Tristan Gingold <gingold@adacore.com> wrote:
>
> On Mar 16, 2011, at 7:44 AM, Sedat Dilek wrote:
>
>> Hi,
>>
>> while handling several breakages in linux-next kernel, it showed PR
>> gas/12519 (see [1]) is somehow incomplete as it gives no pointer to
>> the symbol name in case of an error.
>> "Mention symbol name in non-constant .size expression." (see [2]) as a
>> follow-up patch definitely helps to enlighten developer's where to dig
>> into occuring problems.
>> "Revert the last change on gas/elf/bad-size.err." (see [3]) is a fixup to [2].
>>
>> It would be nice to see [2] and [3] backported to 2.21-branch.
>
> Why not.
>
> Does it make sense to generate a warning instead of an error in 2.21.1 for backward bug-compatibility ?
> Alan, what's your opinion ?
>
> Tristan.
>
>

H.J. offered a proposal patch ("PATCH: Add
--size-check=[error|warning]") [1] with an easy switch opportunity and
H. Peter Anvin illustrated how the warning switch can be used from
command-line [2].

IIRC there was no official decision what will be the default behaviour:
binutils developers mostly advocate "error" as default, whereas  a lot
of Linux kernel developers want "warning" as default.

Unfortunately, I could not apply (and test) H.J.'s proposal patch and
requested a proper one [3].

- Sedat -


[1] http://sourceware.org/ml/binutils/2011-03/msg00214.html
[2] http://sourceware.org/ml/binutils/2011-03/msg00283.html
[3] http://sourceware.org/ml/binutils/2011-03/msg00263.html

Re: Release 2.21.1 ?

[Alan Modra]

On Wed, Mar 16, 2011 at 09:50:35AM +0100, Tristan Gingold wrote:
> 
> On Mar 16, 2011, at 7:44 AM, Sedat Dilek wrote:
> 
> > Hi,
> > 
> > while handling several breakages in linux-next kernel, it showed PR
> > gas/12519 (see [1]) is somehow incomplete as it gives no pointer to
> > the symbol name in case of an error.
> > "Mention symbol name in non-constant .size expression." (see [2]) as a
> > follow-up patch definitely helps to enlighten developer's where to dig
> > into occuring problems.
> > "Revert the last change on gas/elf/bad-size.err." (see [3]) is a fixup to [2].
> > 
> > It would be nice to see [2] and [3] backported to 2.21-branch.
> 
> Why not.
> 
> Does it make sense to generate a warning instead of an error in 2.21.1 for backward bug-compatibility ?
> Alan, what's your opinion ?

Well, it's plain wrong to accept bad expressions and have gas try to
guess what typos mean, so I think it should be an error.  The size
info matters to some people.  Ask gdb developers, or anyone writing
code analysis and optimization tools.

I also think it highly likely that new binutils and/or gcc will break
kernel bisection in other areas.  For that reason I'm inclined to
discount the kernel list histrionics over the .size fix.  Kernel
kiddies are just going to have to learn to deal with toolchain
evolution.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Release 2.21.1 ?

[H.J. Lu]

On Wed, Mar 16, 2011 at 5:16 AM, Alan Modra <amodra@gmail.com> wrote:
> On Wed, Mar 16, 2011 at 09:50:35AM +0100, Tristan Gingold wrote:
>>
>> On Mar 16, 2011, at 7:44 AM, Sedat Dilek wrote:
>>
>> > Hi,
>> >
>> > while handling several breakages in linux-next kernel, it showed PR
>> > gas/12519 (see [1]) is somehow incomplete as it gives no pointer to
>> > the symbol name in case of an error.
>> > "Mention symbol name in non-constant .size expression." (see [2]) as a
>> > follow-up patch definitely helps to enlighten developer's where to dig
>> > into occuring problems.
>> > "Revert the last change on gas/elf/bad-size.err." (see [3]) is a fixup to [2].
>> >
>> > It would be nice to see [2] and [3] backported to 2.21-branch.
>>
>> Why not.
>>
>> Does it make sense to generate a warning instead of an error in 2.21.1 for backward bug-compatibility ?
>> Alan, what's your opinion ?
>
> Well, it's plain wrong to accept bad expressions and have gas try to
> guess what typos mean, so I think it should be an error.  The size
> info matters to some people.  Ask gdb developers, or anyone writing
> code analysis and optimization tools.
>
> I also think it highly likely that new binutils and/or gcc will break
> kernel bisection in other areas.  For that reason I'm inclined to
> discount the kernel list histrionics over the .size fix.  Kernel
> kiddies are just going to have to learn to deal with toolchain
> evolution.
>

Can I apply my size error patch?

Thanks.


-- 
H.J.

Re: Release 2.21.1 ?

[Tristan Gingold]

On Mar 16, 2011, at 1:44 PM, H.J. Lu wrote:

> On Wed, Mar 16, 2011 at 5:16 AM, Alan Modra <amodra@gmail.com> wrote:
>> On Wed, Mar 16, 2011 at 09:50:35AM +0100, Tristan Gingold wrote:
>>> 
>>> On Mar 16, 2011, at 7:44 AM, Sedat Dilek wrote:
>>> 
>>>> Hi,
>>>> 
>>>> while handling several breakages in linux-next kernel, it showed PR
>>>> gas/12519 (see [1]) is somehow incomplete as it gives no pointer to
>>>> the symbol name in case of an error.
>>>> "Mention symbol name in non-constant .size expression." (see [2]) as a
>>>> follow-up patch definitely helps to enlighten developer's where to dig
>>>> into occuring problems.
>>>> "Revert the last change on gas/elf/bad-size.err." (see [3]) is a fixup to [2].
>>>> 
>>>> It would be nice to see [2] and [3] backported to 2.21-branch.
>>> 
>>> Why not.
>>> 
>>> Does it make sense to generate a warning instead of an error in 2.21.1 for backward bug-compatibility ?
>>> Alan, what's your opinion ?
>> 
>> Well, it's plain wrong to accept bad expressions and have gas try to
>> guess what typos mean, so I think it should be an error.  The size
>> info matters to some people.  Ask gdb developers, or anyone writing
>> code analysis and optimization tools.
>> 
>> I also think it highly likely that new binutils and/or gcc will break
>> kernel bisection in other areas.  For that reason I'm inclined to
>> discount the kernel list histrionics over the .size fix.  Kernel
>> kiddies are just going to have to learn to deal with toolchain
>> evolution.
>> 
> 
> Can I apply my size error patch?

Sure.

Re: Release 2.21.1 ?

[Sedat Dilek]

On Wed, Mar 16, 2011 at 10:37 AM, Sedat Dilek
<sedat.dilek@googlemail.com> wrote:
> On Wed, Mar 16, 2011 at 9:50 AM, Tristan Gingold <gingold@adacore.com> wrote:
>>
>> On Mar 16, 2011, at 7:44 AM, Sedat Dilek wrote:
>>
>>> Hi,
>>>
>>> while handling several breakages in linux-next kernel, it showed PR
>>> gas/12519 (see [1]) is somehow incomplete as it gives no pointer to
>>> the symbol name in case of an error.
>>> "Mention symbol name in non-constant .size expression." (see [2]) as a
>>> follow-up patch definitely helps to enlighten developer's where to dig
>>> into occuring problems.
>>> "Revert the last change on gas/elf/bad-size.err." (see [3]) is a fixup to [2].
>>>
>>> It would be nice to see [2] and [3] backported to 2.21-branch.
>>
>> Why not.
>>
>> Does it make sense to generate a warning instead of an error in 2.21.1 for backward bug-compatibility ?
>> Alan, what's your opinion ?
>>
>> Tristan.
>>
>>
>
> H.J. offered a proposal patch ("PATCH: Add
> --size-check=[error|warning]") [1] with an easy switch opportunity and
> H. Peter Anvin illustrated how the warning switch can be used from
> command-line [2].
>
> IIRC there was no official decision what will be the default behaviour:
> binutils developers mostly advocate "error" as default, whereas  a lot
> of Linux kernel developers want "warning" as default.
>
> Unfortunately, I could not apply (and test) H.J.'s proposal patch and
> requested a proper one [3].
>
> - Sedat -
>
>
> [1] http://sourceware.org/ml/binutils/2011-03/msg00214.html
> [2] http://sourceware.org/ml/binutils/2011-03/msg00283.html
> [3] http://sourceware.org/ml/binutils/2011-03/msg00263.html
>

Hi,

I have cherry-picked commit 8bba209217cab2e7fb949768ffc4a5d40ecc144a
("Add --size-check=[error|warning].") from upstream and built a Debian
package on top of binutils (2.21.0.20110302-2) source package.

I returned to the linux-next (next-20110308) which I reported as
"broken" and currently building a new kernel (it's not finished yet,
make -j=1).

Instructions:

$ cd $BUILD_DIR
$ make CC='gcc -Wa,--size-check=warning'

Check current build-log:

$ egrep 'Assembler messages:|Warning: .size expression with symbol'
build.log
/home/sd/src/linux-2.6/linux-2.6.38-rc7/debian/build/source_i386_none/arch/x86/kernel/entry_32.S:
Assembler messages:
/home/sd/src/linux-2.6/linux-2.6.38-rc7/debian/build/source_i386_none/arch/x86/kernel/entry_32.S:1421:
Warning: .size expression with symbol `apf_page_fault' does not
evaluate to a constant
/home/sd/src/linux-2.6/linux-2.6.38-rc7/debian/build/source_i386_none/arch/x86/kernel/acpi/wakeup_rm.S:
Assembler messages:
/home/sd/src/linux-2.6/linux-2.6.38-rc7/debian/build/source_i386_none/arch/x86/kernel/acpi/wakeup_rm.S:12:
Warning: .size expression with symbol `wakeup_code_start' does not
evaluate to a constant
...

Nice, it works as expected :-).
( These were the two places I discovered, but this time the kernel
building is not interrupted. )

/me is just fine with the default behaviour of (my freshly-built)
binutils/as "--size-check=error".

Thanks to all involved people for their help, especially to H.J. for
providing a patch and solution!

Regards,
- Sedat -

P.S.: These 3 patches should be backported to 2.21-branch.

$ LC_ALL=C ls -l patches
total 16
-rw-r--r-- 1 sd sd 3137 Mar 16 14:45
0001-Mention-symbol-name-in-non-constant-.size-expression.patch
-rw-r--r-- 1 sd sd  948 Mar 16 14:45
0002-Revert-the-last-change-on-gas-elf-bad-size.err.patch
-rw-r--r-- 1 sd sd 7782 Mar 16 14:45 0003-Add-size-check-error-warning.patch

Re: Release 2.21.1 ?

[Tristan Gingold]

On May 17, 2011, at 7:30 PM, Andreas Krebbel wrote:

>> Yes, that's OK.
> 
> Here is the backport for 2.21 of:
> 
> [PATCH] S/390: Support the .machine pseudo
> http://sourceware.org/ml/binutils/2011-04/msg00191.html
> 
> the backported patch also includes the trivial change:
> 
> [Committed] S/390: gas: Add -march=all
> http://sourceware.org/ml/binutils/2011-03/msg00355.html
> 
> Ok for 2.21?

Sure.

Re: Release 2.21.1 ?

[Andreas Krebbel]

> Yes, that's OK.

Here is the backport for 2.21 of:

[PATCH] S/390: Support the .machine pseudo
http://sourceware.org/ml/binutils/2011-04/msg00191.html

the backported patch also includes the trivial change:

[Committed] S/390: gas: Add -march=all
http://sourceware.org/ml/binutils/2011-03/msg00355.html

Ok for 2.21?

Bye,

-Andreas-


2011-05-17  Andreas Krebbel  <Andreas.Krebbel@de.ibm.com>

	Backported from mainline
	2011-03-18  Andreas Krebbel  <Andreas.Krebbel@de.ibm.com>

	* config/tc-s390.c (md_parse_option): Add -march=all option which
	switches to the highest available CPU.

	2011-04-14  Andreas Krebbel  <Andreas.Krebbel@de.ibm.com>

	* config/tc-s390.c (s390_machine): New prototype.
	(md_pseudo_table): New pseudo-op .machine.
	(s390_opcode_hash): Initialize to NULL.
	(s390_parse_cpu): New function.
	(md_parse_option): Use s390_parse_cpu.
	(s390_setup_opcodes): New function.
	(md_begin): Use s390_setup_opcodes.
	(s390_machine): New hook handling the new .machine pseudo.

	* doc/c-s390.texi: Document the new pseudo op .machine.


2011-05-17  Andreas Krebbel  <Andreas.Krebbel@de.ibm.com>

	    Backported from mainline
	    2011-04-14  Andreas Krebbel  <Andreas.Krebbel@de.ibm.com>

	    * gas/s390/zarch-machine.s: New testcase.
	    * gas/s390/zarch-machine.d: New testcase output.
	    * gas/s390/s390.exp: Execute the new testcase.


Index: gas/config/tc-s390.c
===================================================================
--- gas/config/tc-s390.c.orig
+++ gas/config/tc-s390.c
@@ -85,6 +85,7 @@ static void s390_elf_cons (int);
 static void s390_bss (int);
 static void s390_insn (int);
 static void s390_literals (int);
+static void s390_machine (int);
 
 const pseudo_typeS md_pseudo_table[] =
 {
@@ -99,6 +100,7 @@ const pseudo_typeS md_pseudo_table[] =
   { "quad",     s390_elf_cons,  8 },
   { "ltorg",    s390_literals,  0 },
   { "string",   stringer,       8 + 1 },
+  { "machine",  s390_machine,   0 },
   { NULL,	NULL,		0 }
 };
 
@@ -293,7 +295,7 @@ register_name (expressionS *expressionP)
 static struct hash_control *s390_opformat_hash;
 
 /* Opcode hash table.  */
-static struct hash_control *s390_opcode_hash;
+static struct hash_control *s390_opcode_hash = NULL;
 
 /* Flags to set in the elf header */
 static flagword s390_flags = 0;
@@ -350,6 +352,35 @@ s390_target_format (void)
   return s390_arch_size == 64 ? "elf64-s390" : "elf32-s390";
 }
 
+/* Map a CPU string as given with -march= or .machine to the
+   respective enum s390_opcode_cpu_val value.  0xffffffff is returned
+   in case of an error.  */
+
+static unsigned int
+s390_parse_cpu (char *arg)
+{
+  if (strcmp (arg, "g5") == 0)
+    return S390_OPCODE_G5;
+  else if (strcmp (arg, "g6") == 0)
+    return S390_OPCODE_G6;
+  else if (strcmp (arg, "z900") == 0)
+    return S390_OPCODE_Z900;
+  else if (strcmp (arg, "z990") == 0)
+    return S390_OPCODE_Z990;
+  else if (strcmp (arg, "z9-109") == 0)
+    return S390_OPCODE_Z9_109;
+  else if (strcmp (arg, "z9-ec") == 0)
+    return S390_OPCODE_Z9_EC;
+  else if (strcmp (arg, "z10") == 0)
+    return S390_OPCODE_Z10;
+  else if (strcmp (arg, "z196") == 0)
+    return S390_OPCODE_Z196;
+  else if (strcmp (arg, "all") == 0)
+    return S390_OPCODE_MAXCPU - 1;
+  else
+    return -1;
+}
+
 int
 md_parse_option (int c, char *arg)
 {
@@ -382,23 +413,9 @@ md_parse_option (int c, char *arg)
 
       else if (arg != NULL && strncmp (arg, "arch=", 5) == 0)
 	{
-	  if (strcmp (arg + 5, "g5") == 0)
-	    current_cpu = S390_OPCODE_G5;
-	  else if (strcmp (arg + 5, "g6") == 0)
-	    current_cpu = S390_OPCODE_G6;
-	  else if (strcmp (arg + 5, "z900") == 0)
-	    current_cpu = S390_OPCODE_Z900;
-	  else if (strcmp (arg + 5, "z990") == 0)
-	    current_cpu = S390_OPCODE_Z990;
-	  else if (strcmp (arg + 5, "z9-109") == 0)
-	    current_cpu = S390_OPCODE_Z9_109;
-	  else if (strcmp (arg + 5, "z9-ec") == 0)
-	    current_cpu = S390_OPCODE_Z9_EC;
-	  else if (strcmp (arg + 5, "z10") == 0)
-	    current_cpu = S390_OPCODE_Z10;
-	  else if (strcmp (arg + 5, "z196") == 0)
-	    current_cpu = S390_OPCODE_Z196;
-	  else
+	  current_cpu = s390_parse_cpu (arg + 5);
+
+	  if (current_cpu == (unsigned int)-1)
 	    {
 	      as_bad (_("invalid switch -m%s"), arg);
 	      return 0;
@@ -454,42 +471,20 @@ md_show_usage (FILE *stream)
         -Qy, -Qn          ignored\n"));
 }
 
-/* This function is called when the assembler starts up.  It is called
-   after the options have been parsed and the output file has been
-   opened.  */
+/* Generate the hash table mapping mnemonics to struct s390_opcode.
+   This table is built at startup and whenever the CPU level is
+   changed using .machine.  */
 
-void
-md_begin (void)
+static void
+s390_setup_opcodes (void)
 {
   register const struct s390_opcode *op;
   const struct s390_opcode *op_end;
   bfd_boolean dup_insn = FALSE;
   const char *retval;
 
-  /* Give a warning if the combination -m64-bit and -Aesa is used.  */
-  if (s390_arch_size == 64 && current_cpu < S390_OPCODE_Z900)
-    as_warn (_("The 64 bit file format is used without esame instructions."));
-
-  s390_cie_data_alignment = -s390_arch_size / 8;
-
-  /* Set the ELF flags if desired.  */
-  if (s390_flags)
-    bfd_set_private_flags (stdoutput, s390_flags);
-
-  /* Insert the opcode formats into a hash table.  */
-  s390_opformat_hash = hash_new ();
-
-  op_end = s390_opformats + s390_num_opformats;
-  for (op = s390_opformats; op < op_end; op++)
-    {
-      retval = hash_insert (s390_opformat_hash, op->name, (void *) op);
-      if (retval != (const char *) NULL)
-	{
-	  as_bad (_("Internal assembler error for instruction format %s"),
-		  op->name);
-	  dup_insn = TRUE;
-	}
-    }
+  if (s390_opcode_hash != NULL)
+    hash_die (s390_opcode_hash);
 
   /* Insert the opcodes into a hash table.  */
   s390_opcode_hash = hash_new ();
@@ -521,11 +516,50 @@ md_begin (void)
 
   if (dup_insn)
     abort ();
+}
+
+/* This function is called when the assembler starts up.  It is called
+   after the options have been parsed and the output file has been
+   opened.  */
+
+void
+md_begin (void)
+{
+  register const struct s390_opcode *op;
+  const struct s390_opcode *op_end;
+  bfd_boolean dup_insn = FALSE;
+  const char *retval;
+
+  /* Give a warning if the combination -m64-bit and -Aesa is used.  */
+  if (s390_arch_size == 64 && current_cpu < S390_OPCODE_Z900)
+    as_warn (_("The 64 bit file format is used without esame instructions."));
+
+  s390_cie_data_alignment = -s390_arch_size / 8;
+
+  /* Set the ELF flags if desired.  */
+  if (s390_flags)
+    bfd_set_private_flags (stdoutput, s390_flags);
+
+  /* Insert the opcode formats into a hash table.  */
+  s390_opformat_hash = hash_new ();
+
+  op_end = s390_opformats + s390_num_opformats;
+  for (op = s390_opformats; op < op_end; op++)
+    {
+      retval = hash_insert (s390_opformat_hash, op->name, (void *) op);
+      if (retval != (const char *) NULL)
+	{
+	  as_bad (_("Internal assembler error for instruction format %s"),
+		  op->name);
+	  dup_insn = TRUE;
+	}
+    }
+
+  s390_setup_opcodes ();
 
   record_alignment (text_section, 2);
   record_alignment (data_section, 2);
   record_alignment (bss_section, 2);
-
 }
 
 /* Called after all assembly has been done.  */
@@ -1753,6 +1787,72 @@ s390_literals (int ignore ATTRIBUTE_UNUS
   lpe_count = 0;
 }
 
+/* The .machine pseudo op allows to switch to a different CPU level in
+   the asm listing.  The current CPU setting can be stored on a stack
+   with .machine push and restored with .machined pop.  */
+
+static void
+s390_machine (int ignore ATTRIBUTE_UNUSED)
+{
+  char *cpu_string;
+#define MAX_HISTORY 100
+  static unsigned int *cpu_history;
+  static int curr_hist;
+
+  SKIP_WHITESPACE ();
+
+  if (*input_line_pointer == '"')
+    {
+      int len;
+      cpu_string = demand_copy_C_string (&len);
+    }
+  else
+    {
+      char c;
+      cpu_string = input_line_pointer;
+      c = get_symbol_end ();
+      cpu_string = xstrdup (cpu_string);
+      *input_line_pointer = c;
+    }
+
+  if (cpu_string != NULL)
+    {
+      unsigned int old_cpu = current_cpu;
+      unsigned int new_cpu;
+      char *p;
+
+      for (p = cpu_string; *p != 0; p++)
+	*p = TOLOWER (*p);
+
+      if (strcmp (cpu_string, "push") == 0)
+	{
+	  if (cpu_history == NULL)
+	    cpu_history = xmalloc (MAX_HISTORY * sizeof (*cpu_history));
+
+	  if (curr_hist >= MAX_HISTORY)
+	    as_bad (_(".machine stack overflow"));
+	  else
+	    cpu_history[curr_hist++] = current_cpu;
+	}
+      else if (strcmp (cpu_string, "pop") == 0)
+	{
+	  if (curr_hist <= 0)
+	    as_bad (_(".machine stack underflow"));
+	  else
+	    current_cpu = cpu_history[--curr_hist];
+	}
+      else if ((new_cpu = s390_parse_cpu (cpu_string)) != (unsigned int)-1)
+	current_cpu = new_cpu;
+      else
+	as_bad (_("invalid machine `%s'"), cpu_string);
+
+      if (current_cpu != old_cpu)
+	s390_setup_opcodes ();
+    }
+
+  demand_empty_rest_of_line ();
+}
+
 char *
 md_atof (int type, char *litp, int *sizep)
 {
Index: gas/doc/c-s390.texi
===================================================================
--- gas/doc/c-s390.texi.orig
+++ gas/doc/c-s390.texi
@@ -851,6 +851,17 @@ ELF extension documentation @samp{ELF Ha
 @item .ltorg
 This directive causes the current contents of the literal pool to be
 dumped to the current location (@ref{s390 Literal Pool Entries}).
+
+@cindex @code{.machine} directive, s390
+@item .machine string
+This directive allows you to change the machine for which code is
+generated.  @code{string} may be any of the @code{-march=} selection
+options (without the -march=), @code{push}, or @code{pop}.
+@code{.machine push} saves the currently selected cpu, which may be
+restored with @code{.machine pop}.  Be aware that the cpu string has
+to be put into double quotes in case it contains characters not
+appropriate for identifiers.  So you have to write @code{"z9-109"}
+instead of just @code{z9-109}.
 @end table
 
 @node s390 Floating Point
Index: gas/testsuite/gas/s390/zarch-machine.d
===================================================================
--- /dev/null
+++ gas/testsuite/gas/s390/zarch-machine.d
@@ -0,0 +1,12 @@
+#name: s390x machine
+#objdump: -dr
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+.* <foo>:
+.*:	e3 95 af ff 00 08 [ 	]*ag	%r9,4095\(%r5,%r10\)
+.*:	eb d6 65 b3 01 6a [ 	]*asi	5555\(%r6\),-42
+.*:	e3 95 af ff 00 18 [ 	]*agf	%r9,4095\(%r5,%r10\)
+.*:	07 07 [ 	]*nopr	%r7
Index: gas/testsuite/gas/s390/zarch-machine.s
===================================================================
--- /dev/null
+++ gas/testsuite/gas/s390/zarch-machine.s
@@ -0,0 +1,8 @@
+.text
+foo:
+	ag	%r9,4095(%r5,%r10)
+.machine push
+.machine z10
+	asi	5555(%r6),-42
+.machine pop
+	agf	%r9,4095(%r5,%r10)
Index: gas/testsuite/gas/s390/s390.exp
===================================================================
--- gas/testsuite/gas/s390/s390.exp.orig
+++ gas/testsuite/gas/s390/s390.exp
@@ -27,4 +27,5 @@ if [expr [istarget "s390-*-*"] ||  [ista
     run_dump_test "zarch-z196" "{as -m64} {as -march=z196}"
     run_dump_test "zarch-reloc" "{as -m64}"
     run_dump_test "zarch-operands" "{as -m64} {as -march=z9-109}"
+    run_dump_test "zarch-machine" "{as -m64} {as -march=z900}"
 }

Re: Release 2.21.1 ?

[Marek Polacek]

On 05/16/2011 09:47 AM, Andreas Krebbel wrote:
> [PATCH] S/390: Support the .machine pseudo
> http://sourceware.org/ml/binutils/2011-04/msg00191.html
> 
> in a binutils release asap in order to fix a glibc s390 build issue with the iconv modules:

Perfect, thanks a lot Andreas.  I'll try to rebuild glibc when this is out.

	Marek

Re: Release 2.21.1 ?

[Tristan Gingold]

On May 16, 2011, at 9:47 AM, Andreas Krebbel wrote:

> On 03/15/2011 09:21 AM, Tristan Gingold wrote:
>> Hi,
>> 
>> now that gcc 4.6 is released, I'd like to know if binutils developers want a new binutils release.
>> Opinions are welcome...
>> 
>> [ I think that not all patches have been back-ported, so do not hesitate to ping me ]
> 
> Although it isn't a binutils bugfix I need a backport of:
> 
> [PATCH] S/390: Support the .machine pseudo
> http://sourceware.org/ml/binutils/2011-04/msg00191.html
> 
> in a binutils release asap in order to fix a glibc s390 build issue with the iconv modules:
> 
> [PATCH] S/390: Use .machine to prevent AS from complaining about z9-109 instructions in
> iconv modules
> http://sources.redhat.com/ml/libc-alpha/2011-04/msg00021.html
> 
> Would you accept a backport of this patch in the 2.21 branch?

Yes, that's OK.

Re: Release 2.21.1 ?

[Andreas Krebbel]

On 03/15/2011 09:21 AM, Tristan Gingold wrote:
> Hi,
> 
> now that gcc 4.6 is released, I'd like to know if binutils developers want a new binutils release.
> Opinions are welcome...
> 
> [ I think that not all patches have been back-ported, so do not hesitate to ping me ]

Although it isn't a binutils bugfix I need a backport of:

[PATCH] S/390: Support the .machine pseudo
http://sourceware.org/ml/binutils/2011-04/msg00191.html

in a binutils release asap in order to fix a glibc s390 build issue with the iconv modules:

[PATCH] S/390: Use .machine to prevent AS from complaining about z9-109 instructions in
iconv modules
http://sources.redhat.com/ml/libc-alpha/2011-04/msg00021.html

Would you accept a backport of this patch in the 2.21 branch?

Bye,

-Andreas-

Re: Release 2.21.1 ?

[Tristan Gingold]

On Mar 20, 2011, at 10:22 PM, Mike Frysinger wrote:

> On Tuesday, March 15, 2011 04:21:37 Tristan Gingold wrote:
>> [ I think that not all patches have been back-ported, so do not hesitate to
>> ping me ]
> 
> this one would be good in the branch:
> http://sourceware.org/git/?p=binutils.git;a=commitdiff;h=3963724636741cd14e6de65267731c15cd492ecf
> 
> without this, glibc crashes when building for some cpus (like C3-2's)

Done.

Re: Release 2.21.1 ?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 363 bytes --]

On Tuesday, March 15, 2011 04:21:37 Tristan Gingold wrote:
> [ I think that not all patches have been back-ported, so do not hesitate to
> ping me ]

this one would be good in the branch:
http://sourceware.org/git/?p=binutils.git;a=commitdiff;h=3963724636741cd14e6de65267731c15cd492ecf

without this, glibc crashes when building for some cpus (like C3-2's)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Release 2.21.1 ?

[Tristan Gingold]

On Mar 17, 2011, at 1:21 PM, Alan Modra wrote:

> On Wed, Mar 16, 2011 at 09:49:19AM +0100, Tristan Gingold wrote:
>> This patch is supposed to be in 2.21:
>> 
>> 	2010-12-20  Alan Modra  <amodra@gmail.com>
> [snip]
>> But it looks like it was only partially backported (chunks still apply to ldlang.[ch] and ldemul.c)
>> 
>> Alan ?
> 
> Nothing appears to be missing.  A followup patch 2011-01-13 no doubt
> removed those hunks.

Fine.  Thank you for the investigation.

Tristan.

Re: Release 2.21.1 ?

[Alan Modra]

On Wed, Mar 16, 2011 at 09:49:19AM +0100, Tristan Gingold wrote:
> This patch is supposed to be in 2.21:
> 
> 	2010-12-20  Alan Modra  <amodra@gmail.com>
[snip]
> But it looks like it was only partially backported (chunks still apply to ldlang.[ch] and ldemul.c)
> 
> Alan ?

Nothing appears to be missing.  A followup patch 2011-01-13 no doubt
removed those hunks.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Release 2.21.1 ?

[Alan Modra]

On Wed, Mar 16, 2011 at 09:49:19AM +0100, Tristan Gingold wrote:
> But it looks like it was only partially backported (chunks still apply to ldlang.[ch] and ldemul.c)

I'll take a look tomorrow.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Release 2.21.1 ?

[Tristan Gingold]

On Mar 16, 2011, at 5:03 AM, Mike Frysinger wrote:

> On Tuesday, March 15, 2011 04:21:37 Tristan Gingold wrote:
>> [ I think that not all patches have been back-ported, so do not hesitate to
>> ping me ]
> 
> my understanding is that binutils-2.21 does not build a relocatable x86 
> kernel, but this commit from master fixes it:
> http://sourceware.org/git/?p=binutils.git;a=commit;h=5daebc6a6606a30e60716f5bdee3d2018b560e8e
> 
> so that'd be a good one to backport if a new release is done

This patch is supposed to be in 2.21:

	2010-12-20  Alan Modra  <amodra@gmail.com>
	PR ld/12327
	* ld.texinfo (Expression Section): Describe treatment of numbers
	and absolute symbols.
	* ldemul.c (after_open_default): Look up __ld_compatibility.
	* ldexp.c (fold_name): Convert absolute symbols to numbers when
	inside output section definitions, or when __ld_compatibility >= 221.
	(exp_fold_tree_1): Convert numbers to absolute when not in output
	section definition and __ld_compatibility < 221.  Don't always
	convert values outside an output section definition to absolute.
	* ldexp.h (uses_defined): Comment.
	* ldlang.c (ld_compatibility): New variable.
	* ldlang.h (ld_compatibility): Declare.
	* emultempl/aix.em, * emultempl/armcoff.em, * emultempl/beos.em,
	* emultempl/elf32.em, * emultempl/genelf.em, * emultempl/lnk960.em,
	* emultempl/m68kcoff.em, * emultempl/mmo.em, * emultempl/pe.em,
	* emultempl/pep.em, * emultempl/sunos.em, * emultempl/z80.em: Call
	after_open_default from after_open function.

But it looks like it was only partially backported (chunks still apply to ldlang.[ch] and ldemul.c)

Alan ?

Tristan.

Re: Release 2.21.1 ?

[Tristan Gingold]

On Mar 15, 2011, at 6:50 PM, Dave Korn wrote:

> On 15/03/2011 17:30, Matthias Klose wrote:
>> On 15.03.2011 09:21, Tristan Gingold wrote:
>>> now that gcc 4.6 is released, I'd like to know if binutils developers want a new binutils release.
>>> Opinions are welcome...
>>> 
>>> [ I think that not all patches have been back-ported, so do not hesitate to ping me ]
>> 
>> what is the status of Dave Korn's plugin patches?
>> 
>>  Matthias
> 
>  There's still one outstanding LTO issue that needs solving on HEAD and then
> a backport of all the plugin-api updates to the branch.  The one outstanding
> issue is the pr12365/2-stage link discussion which I'm about to revive, having
> spent the past little while trying a few different approaches.

I think Dave's plugin patches should be included in 2.21.1 - so I will wait until the backport.

Tristan.

Re: Release 2.21.1 ?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 441 bytes --]

On Tuesday, March 15, 2011 04:21:37 Tristan Gingold wrote:
> [ I think that not all patches have been back-ported, so do not hesitate to
> ping me ]

my understanding is that binutils-2.21 does not build a relocatable x86 
kernel, but this commit from master fixes it:
http://sourceware.org/git/?p=binutils.git;a=commit;h=5daebc6a6606a30e60716f5bdee3d2018b560e8e

so that'd be a good one to backport if a new release is done
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Release 2.21.1 ?

[Dave Korn]

On 15/03/2011 17:30, Matthias Klose wrote:
> On 15.03.2011 09:21, Tristan Gingold wrote:
>> now that gcc 4.6 is released, I'd like to know if binutils developers want a new binutils release.
>> Opinions are welcome...
>>
>> [ I think that not all patches have been back-ported, so do not hesitate to ping me ]
> 
> what is the status of Dave Korn's plugin patches?
> 
>   Matthias

  There's still one outstanding LTO issue that needs solving on HEAD and then
a backport of all the plugin-api updates to the branch.  The one outstanding
issue is the pr12365/2-stage link discussion which I'm about to revive, having
spent the past little while trying a few different approaches.

    cheers,
      DaveK

Re: Release 2.21.1 ?

[Matthias Klose]

On 15.03.2011 09:21, Tristan Gingold wrote:
> now that gcc 4.6 is released, I'd like to know if binutils developers want a new binutils release.
> Opinions are welcome...
> 
> [ I think that not all patches have been back-ported, so do not hesitate to ping me ]

what is the status of Dave Korn's plugin patches?

  Matthias

Re: Release 2.21.1 ?

[Jakub Jelinek]

On Tue, Mar 15, 2011 at 09:21:37AM +0100, Tristan Gingold wrote:
> now that gcc 4.6 is released, I'd like to know if binutils developers want a new binutils release.

Just small correction, gcc 4.6.0 hasn't been released, but it will be hopefully soon.
Only gcc 4.6.0-rc1 has been pushed for testing...

	Jakub

Re: Release 2.21.1 ?

[Ian Lance Taylor]

Tristan Gingold <gingold@adacore.com> writes:

> now that gcc 4.6 is released, I'd like to know if binutils developers want a new binutils release.

I would like to see a binutils 2.21.1 release at some point.

Ian

Release 2.21.1 ?

[Tristan Gingold]

Hi,

now that gcc 4.6 is released, I'd like to know if binutils developers want a new binutils release.
Opinions are welcome...

[ I think that not all patches have been back-ported, so do not hesitate to ping me ]

Tristan