Re: [parisc-linux] [PATCH] hppa-linux-gas binutils patch

Re: [parisc-linux] [PATCH] hppa-linux-gas binutils patch

[John David Anglin]

> The GAS manual says:
> ---
> .equ symbol, expression
> This directive sets the value of symbol to expression. It is
> synonymous with `.set'; see section .set symbol, expression.
> The syntax for equ on the HPPA is `symbol .equ expression'.
> ---
> 
> This should be updated.
> 
> Have you considered the implications of your patch to porting HPUX assembly?
> Does the HPUX assembler have an .equ directive? Dave can probably
> answer that so I'll CC him.
> 
> ---
> label .reg expr
>     Synonym for .equ; define label with the absolute expression expr
> as its value.
> ---
> 
> In summary... if you provide a documentation patch I'll test this and
> submit upstream. When upstreams gives the green flag I'll check this
> into binutils head.

This needs testing on hpux.  I believe there may be problems.
The current implementation reflects the syntax for .equ using HP as.

The HP assembler only allows an integer expression which evalutes
to an absolute value.  The HP assembler prohibits the use of
relocatable labels and imported symbols as a component of a
.equ expression.  This reflected the capabilites of HP ld at
one time.  This may not reflect current capabilites.  There may
be differences between the 32 and 64-bit linkers.  I'm cautious
here as I know .set which has no HP assembler equivalent works
most of the time, but the capabilities of HP ld aren't well
documented and there are subtle issues in assigning aliases.
There are some uses of .set in the gas testsuite which run under
hpux and they seem to work at basic level.  However, the weak
alias stuff isn't useful under hpux because of the way HP ld
handles "weak" symbols.

On the otherhand, more latitude on the expression is allowed when
GNU ld is being used.  .equ is effectively a synonym for .set.  
Because of this, I haven't been too concerned about the syntax
for .equ.  There are various other directives that also follow the
HP syntax.  In summary, these probably should be changed to follow
the standard behavior under linux, etc; but I think the current
behavior should be retained under hpux.

Sorry, I haven't had a chance to look at the details of your change.
I've been busy and a few GCC targets are broken...

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] [PATCH] hppa-linux-gas binutils patch

[Helge Deller]

Hi Dave,
Hi Carlos,

Somehow I lost Carlos answer to my mail, so I'll wind his questions and my answers in here:

Carlos> Out of curiosity do you have a copyright assignment for binutils? 
Carlos> If not, then that is OK, I can submit your patch upstream
Carlos> and check it in aswell.

I'm right now in the process to get this assignment done.
Since I think this will take some time, I'd prefer if you could submit 
it upstream (if everyone agrees).


On Monday 27 November 2006 02:34, John David Anglin wrote:
> > The GAS manual says:
> > ---
> > .equ symbol, expression
> > This directive sets the value of symbol to expression. It is
> > synonymous with `.set'; see section .set symbol, expression.
> > The syntax for equ on the HPPA is `symbol .equ expression'.
> > ---
> > 
> > This should be updated.

Sure.
I'll send an updated patch soon.

> > Have you considered the implications of your patch to porting HPUX assembly?
> > Does the HPUX assembler have an .equ directive? Dave can probably
> > answer that so I'll CC him.
> > 
> > ---
> > label .reg expr
> >     Synonym for .equ; define label with the absolute expression expr
> > as its value.
> > ---
> > 
> This needs testing on hpux.  I believe there may be problems.
> The current implementation reflects the syntax for .equ using HP as.
> 
> The HP assembler only allows an integer expression which evalutes
> to an absolute value.  The HP assembler prohibits the use of
> relocatable labels and imported symbols as a component of a
> .equ expression.  This reflected the capabilites of HP ld at
> one time.  This may not reflect current capabilites.  There may
> be differences between the 32 and 64-bit linkers.  I'm cautious
> here as I know .set which has no HP assembler equivalent works
> most of the time, but the capabilities of HP ld aren't well
> documented and there are subtle issues in assigning aliases.
> There are some uses of .set in the gas testsuite which run under
> hpux and they seem to work at basic level.  However, the weak
> alias stuff isn't useful under hpux because of the way HP ld
> handles "weak" symbols.
> 
> On the otherhand, more latitude on the expression is allowed when
> GNU ld is being used.  .equ is effectively a synonym for .set.  
> Because of this, I haven't been too concerned about the syntax
> for .equ.  There are various other directives that also follow the
> HP syntax.  In summary, these probably should be changed to follow
> the standard behavior under linux, etc; but I think the current
> behavior should be retained under hpux.
> 
> Sorry, I haven't had a chance to look at the details of your change.
> I've been busy and a few GCC targets are broken...

The patch only affects the .equ directive. It does not change .set in any way.
It will only allow the case of:
		.equ VAR,VALUE
which was printing an error message before.
So, it doesn't change any currently existing behavior. 
Instead it's only adding a "new way" to use the .equ directive in a typical "gas" way.

As a background story:
Originally I wanted to add support for
VAR		.equ  VALUE
as it's e.g. documented here: http://docs.hp.com/en/92432-90012/ch02.html
(JAN   .equ  1).
But this is in contrast to what gas (in as.info) states, since it does not end with a colon:
"  For HPPA targets, labels need not be immediately followed by a
"colon, but the definition of a label must begin in column zero.  This
"also implies that only one label may be defined on each line.
"    label:     .directive    followed by something
...
Sadly I until now failed to get  this working as well :-(

Helge
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [PATCH] hppa-linux-gas binutils patch

[Helge Deller]

On Tuesday 28 November 2006 20:20, Helge Deller wrote:
> As a background story:
> Originally I wanted to add support for
> VAR		.equ  VALUE
> as it's e.g. documented here: http://docs.hp.com/en/92432-90012/ch02.html
> (JAN   .equ  1).

There is more broken:

deller@c3000:~/binutils/run/bin$ cat test.s
AA       .equ  4
BB      .equ  6
deller@c3000:~/binutils/run/bin$ as test.s
test.s: Assembler messages:
test.s:1: Error: Unknown opcode: `aa'
test.s:2: Error: Invalid operands

although as.info states:

7.37 `.equ SYMBOL, EXPRESSION'
==============================

This directive sets the value of SYMBOL to EXPRESSION.  It is
synonymous with `.set'; see *Note `.set': Set.

   The syntax for `equ' on the HPPA is `SYMBOL .equ EXPRESSION'.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [PATCH] hppa-linux-gas binutils patch

[John David Anglin]

> deller@c3000:~/binutils/run/bin$ cat test.s
> AA       .equ  4
> BB      .equ  6
> deller@c3000:~/binutils/run/bin$ as test.s
> test.s: Assembler messages:
> test.s:1: Error: Unknown opcode: `aa'
> test.s:2: Error: Invalid operands

This is because the linux target was changed to require colons after
labels.  As a result, operands can start in the first column of a line.
Under hpux, there needs to be at least one white space character before
an operand and labels have to start in the first column.

> although as.info states:
> 
> 7.37 `.equ SYMBOL, EXPRESSION'
> ==============================
> 
> This directive sets the value of SYMBOL to EXPRESSION.  It is
> synonymous with `.set'; see *Note `.set': Set.
> 
>    The syntax for `equ' on the HPPA is `SYMBOL .equ EXPRESSION'.

This doesn't reflect that SYMBOL needs to be followed by a colon
on HPPA linux.  So, the documentation needs updating.

Probably, the linux should have been updated to use the normal GNU
syntax when it was introduced.  Now, updating the syntax involves a
potential compatibility break with GCC and existing assembler code.
At the moment, I don't see a strong need to do the update.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] [PATCH] hppa-linux-gas binutils patch

[John David Anglin]

> It will only allow the case of:
> 		.equ VAR,VALUE
> which was printing an error message before.
> So, it doesn't change any currently existing behavior. 

It adds new behavior which was previously invalid.  The above syntax
isn't valid using HP as and previously gas syntax mirrored the HP
syntax.  So, you have to convince the binutils maintainers that the
above extension is compatible with what exists now.  For example,

LABEL:	.equ VALUE
	.equ VAR,VALUE
LABEL1: .equ VAR,VALUE	; ???

Do these all work correctly?

> As a background story:
> Originally I wanted to add support for
> VAR		.equ  VALUE
> as it's e.g. documented here: http://docs.hp.com/en/92432-90012/ch02.html
> (JAN   .equ  1).
> But this is in contrast to what gas (in as.info) states, since it does not end with a colon:
> "  For HPPA targets, labels need not be immediately followed by a
> "colon, but the definition of a label must begin in column zero.  This
> "also implies that only one label may be defined on each line.
> "    label:     .directive    followed by something
> ...
> Sadly I until now failed to get  this working as well :-(

I believe the labels must be followed by followed by a colon on linux.
On hpux, the colon is optional.  HP as wants no colon.  Note that labels
don't have to be on the same line as the directive.  Thus, I believe that

label:	.equ	VALUE

should work on linux.

I'm not sure the in comment in as.info about only one label per line
is correct.  There's a line termination character that allows multiple
directives per line.  It's useful in macros.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] [PATCH] hppa-linux-gas binutils patch

[Helge Deller]

Hi Dave,

On Saturday 02 December 2006 22:13, John David Anglin wrote:
> > a)
> > LABEL: 		.equ VALUE		; NOTE: LABEL with COLON ':'
> > worked before on Linux, will still work. No idea about HPUX
> 
> It works on hpux.
> 
> > b)
> > LABEL 		.equ VALUE		 ; NOTE: LABEL without COLON ':'
> > never worked on Linux, and will still not work. 
> > Standard on HPUX, so gnu as never followed HP-UX here.
> 
> This also works on hpux.  I don't understand your comment about
> GNU as not following the behavior of HP as.  This is the only
> variant allowed by HP as.

I'm not sure why you didn't understood it... Maybe you just mis-read my comment ?
GNU as on Linux does _not_ accept this one, while HP as _accepts_ this syntax only.
So, GNU as and HP as differ in this one, and GNU as does not implement what HP as does.

> > c)
> > 			.equ VAR,VALUE 
> > standard gnu syntax. Didn't worked before on Linux. Will work now.
> > HP-UX probably never allowed this one.
> 
> This isn't good enough.  Either it should work under hpux or be rejected.

I think this is the culprit.
You say, that if this syntax isn't allowed on HP/UX, then it shouldn't be allowed at all on Linux either.

My thinking is, that it seems to be allowed on Linux on most(all?) platforms _except_ PARISC.
The idea of my patch was to make GNU as on Linux/HPPA understand the same things as GNU as on other _Linux_ platforms.
That's completely unrelated to and ignoring what HP as allows or forbid.

> > d)
> > LABEL:		.equ VAR,VALUE
> > never worked on Linux. Will still not work. Use eiter "LABEL:" or "VAR".
> > HP-UX probably never allowed this one.
> 
> Probably, pa_equ should be updated to check that the rest of the line
> is empty.  See s_set for an example.

But then it would be incompatible to HP-as as well.... ?!?
It's inconsitent with your comment to c)

> > @@ -3262,7 +3262,7 @@
> >        return;
> >      }
> >  
> > -  /* Look up the opcode in the has table.  */
> > +  /* Look up the opcode in the hash table.  */
> >    if ((insn = (struct pa_opcode *) hash_find (op_hash, str)) == NULL)
> >      {
> >        as_bad ("Unknown opcode: `%s'", str);
> 
> This typo fix should be a separate patch.  It's fine with the addition
> of a ChangeLog entry.

Ok.

> > @@ -6397,8 +6397,11 @@
> >      {
> >        if (reg)
> >  	as_bad (_(".REG must use a label"));
> > -      else
> > -	as_bad (_(".EQU must use a label"));
> > +      else {
> > +	/* Try gas' standard ".equ X,Y" pseudo opcode.  */
> > +      	s_set(0);
> > +	return;
> > +      }
> 
> I still have a problem with this part.  It drops the ".EQU must use a label"
> error message and s_set has no equivalent error message.  In order to support
> the alternative syntax, you need to parse the rest of the manner similar
> to that done in s_set.  We need a message that handles both ".EQU must use
> a label" and "expected symbol name".

Why do you want the ".EQU must use a label" message ?
Either the user writes
	LABEL:		.equ 5
or
				.equ LABEL , 5
In both variants the user gets a correct error message if the syntax was written wrong.

> The other problem that I see is the dropping of the check on the
> expression value:
> 
>           fudge_reg_expressions = 1;
> 	  seg = expression (&exp);
> 	  fudge_reg_expressions = 0;
> 	  if (exp.X_op != O_constant
> 	      && exp.X_op != O_register)
> 	  ...
> 
> This is likely to be problematic under hpux.  Even under linux,
> the two alternative forms don't handle equivalences in the same
> way.  Compare what assign_symbol does compared with pa_equ.

I would need to check this...
 
> It's certainly possible to do the checks described above.  However,
> I have to wonder if it wouldn't be simpler to just do the following:
> 
> #if !(defined (OBJ_ELF) && (defined (TE_LINUX) || defined (TE_NetBSD)))
>   {"equ", pa_equ, 0},
> #endif
> 
> This would yield the normal GNU syntax under linux and netbsd, and
> retain the existing syntax for other targets.  This might cause some
> current code to fail but it's not a problem for GCC.

I think this is my preferred solution.
(Is there any original HP assembly code at all compiled under Linux with GNU as ?)

> >  @ifset HPPA
> > -The syntax for @code{equ} on the HPPA is 
> > -@samp{@var{symbol} .equ @var{expression}}.
> > +On HPPA the following syntax may be used alternatively:
> > +@samp{@var{symbol:} .equ @var{expression}}
> 
> This also isn't quite right.  See my comment to "b)".  Symbol must
> be a label symbol.

Hmm... I just added the colon. What is exactly wrong ? Do you mean:
+@samp{@var{label:} .equ @var{expression}}

> >  @ifset HPPA
> > -The syntax for @code{set} on the HPPA is
> > -@samp{@var{symbol} .set @var{expression}}.
> > +Alternatively the syntax for @code{set} on the HPPA is
> > +@samp{@var{symbol:} .set @var{expression}}.
> >  @end ifset
> 
> Both the original and proposed change aren't right.  There is no
> special handling for .set on HPPA (see md_pseudo_table).  So, the
> HPPA bit can just be deleted.

Ok.

> In standard GNU syntax, .equ and .set are synonyms.  Since .set has
> the standard behavior, it can be used instead of .equ.  That's why
> I question modifying the syntax of .equ, but I will accept the
> change if it provides a behavior similar to the current behavior.

I see...
- .set can be used instead of .equ
- but: .equ can not be used instead of .set

Or the other alternative would be to just change all ".equ" in ".set" in:
src/binutils/testsuite/binutils-all/localize-hidden-1.s


I'm not sure how to continue now.
I was just playing around with binutils for parisc and the testsuite failed.
My trivial patch fixed it, but it seems there are more changes necessary to
"provide a behavior similar to the current behavior". I think you are right
in asking for this, but personally I don't have time and interest to dig
deeper into this problem.
You said in another mail, that 
"At the moment, I don't see a strong need to do the update."
I agree on this and since it's not really important for me either, I'm better
dropping the whole patch now.

Thanks a lot for your feedback and suggestions,
Helge
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [PATCH] hppa-linux-gas binutils patch

[John David Anglin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 3895 bytes --]

> a)
> LABEL: 		.equ VALUE		; NOTE: LABEL with COLON ':'
> worked before on Linux, will still work. No idea about HPUX

It works on hpux.

> b)
> LABEL 		.equ VALUE		 ; NOTE: LABEL without COLON ':'
> never worked on Linux, and will still not work. 
> Standard on HPUX, so gnu as never followed HP-UX here.

This also works on hpux.  I don't understand your comment about
GNU as not following the behavior of HP as.  This is the only
variant allowed by HP as.

> c)
> 			.equ VAR,VALUE 
> standard gnu syntax. Didn't worked before on Linux. Will work now.
> HP-UX probably never allowed this one.

This isn't good enough.  Either it should work under hpux or be rejected.

> d)
> LABEL:		.equ VAR,VALUE
> never worked on Linux. Will still not work. Use eiter "LABEL:" or "VAR".
> HP-UX probably never allowed this one.

Probably, pa_equ should be updated to check that the rest of the line
is empty.  See s_set for an example.

> @@ -3262,7 +3262,7 @@
>        return;
>      }
>  
> -  /* Look up the opcode in the has table.  */
> +  /* Look up the opcode in the hash table.  */
>    if ((insn = (struct pa_opcode *) hash_find (op_hash, str)) == NULL)
>      {
>        as_bad ("Unknown opcode: `%s'", str);

This typo fix should be a separate patch.  It's fine with the addition
of a ChangeLog entry.

> @@ -6397,8 +6397,11 @@
>      {
>        if (reg)
>  	as_bad (_(".REG must use a label"));
> -      else
> -	as_bad (_(".EQU must use a label"));
> +      else {
> +	/* Try gas' standard ".equ X,Y" pseudo opcode.  */
> +      	s_set(0);
> +	return;
> +      }

I still have a problem with this part.  It drops the ".EQU must use a label"
error message and s_set has no equivalent error message.  In order to support
the alternative syntax, you need to parse the rest of the manner similar
to that done in s_set.  We need a message that handles both ".EQU must use
a label" and "expected symbol name".

The other problem that I see is the dropping of the check on the
expression value:

          fudge_reg_expressions = 1;
	  seg = expression (&exp);
	  fudge_reg_expressions = 0;
	  if (exp.X_op != O_constant
	      && exp.X_op != O_register)
	  ...

This is likely to be problematic under hpux.  Even under linux,
the two alternative forms don't handle equivalences in the same
way.  Compare what assign_symbol does compared with pa_equ.

It's certainly possible to do the checks described above.  However,
I have to wonder if it wouldn't be simpler to just do the following:

#if !(defined (OBJ_ELF) && (defined (TE_LINUX) || defined (TE_NetBSD)))
  {"equ", pa_equ, 0},
#endif

This would yield the normal GNU syntax under linux and netbsd, and
retain the existing syntax for other targets.  This might cause some
current code to fail but it's not a problem for GCC.

>  @ifset HPPA
> -The syntax for @code{equ} on the HPPA is 
> -@samp{@var{symbol} .equ @var{expression}}.
> +On HPPA the following syntax may be used alternatively:
> +@samp{@var{symbol:} .equ @var{expression}}

This also isn't quite right.  See my comment to "b)".  Symbol must
be a label symbol.

>  @ifset HPPA
> -The syntax for @code{set} on the HPPA is
> -@samp{@var{symbol} .set @var{expression}}.
> +Alternatively the syntax for @code{set} on the HPPA is
> +@samp{@var{symbol:} .set @var{expression}}.
>  @end ifset

Both the original and proposed change aren't right.  There is no
special handling for .set on HPPA (see md_pseudo_table).  So, the
HPPA bit can just be deleted.

In standard GNU syntax, .equ and .set are synonyms.  Since .set has
the standard behavior, it can be used instead of .equ.  That's why
I question modifying the syntax of .equ, but I will accept the
change if it provides a behavior similar to the current behavior.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] [PATCH] hppa-linux-gas binutils patch

[Helge Deller]

On Thursday 30 November 2006 17:13, John David Anglin wrote:
> > deller@c3000:~/binutils/run/bin$ cat test.s
> > AA       .equ  4
> > BB      .equ  6
> > deller@c3000:~/binutils/run/bin$ as test.s
> > test.s: Assembler messages:
> > test.s:1: Error: Unknown opcode: `aa'
> > test.s:2: Error: Invalid operands
> 
> This is because the linux target was changed to require colons after
> labels.  ....

yes.

> > although as.info states:
> > 
> > 7.37 `.equ SYMBOL, EXPRESSION'
> > ==============================
> > 
> > This directive sets the value of SYMBOL to EXPRESSION.  It is
> > synonymous with `.set'; see *Note `.set': Set.
> > 
> >    The syntax for `equ' on the HPPA is `SYMBOL .equ EXPRESSION'.
> 
> This doesn't reflect that SYMBOL needs to be followed by a colon
> on HPPA linux.  So, the documentation needs updating.

yes.

> Probably, the linux should have been updated to use the normal GNU
> syntax when it was introduced.  

yes

> Now, updating the syntax involves a 
> potential compatibility break with GCC and existing assembler code.

This is IMHO only true if things suddenly are not allowed any longer which were allowed before.
But my patch just "adds" a new syntax. It does not revert or bails on any existing one.

> At the moment, I don't see a strong need to do the update.

Technically yes, but I think if you have a "gnu as", why not allowing standard gnu style ?

The attached patch updates the documentation and code to additionally allow c):
a)
LABEL: 		.equ VALUE		; NOTE: LABEL with COLON ':'
worked before on Linux, will still work. No idea about HPUX

b)
LABEL 		.equ VALUE		 ; NOTE: LABEL without COLON ':'
never worked on Linux, and will still not work. 
Standard on HPUX, so gnu as never followed HP-UX here.

c)
			.equ VAR,VALUE 
standard gnu syntax. Didn't worked before on Linux. Will work now.
HP-UX probably never allowed this one.

d)
LABEL:		.equ VAR,VALUE
never worked on Linux. Will still not work. Use eiter "LABEL:" or "VAR".
HP-UX probably never allowed this one.


Index: config/tc-hppa.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-hppa.c,v
retrieving revision 1.133
diff -u -r1.133 tc-hppa.c
--- config/tc-hppa.c	30 Oct 2006 01:09:18 -0000	1.133
+++ config/tc-hppa.c	2 Dec 2006 15:10:54 -0000
@@ -3262,7 +3262,7 @@
       return;
     }
 
-  /* Look up the opcode in the has table.  */
+  /* Look up the opcode in the hash table.  */
   if ((insn = (struct pa_opcode *) hash_find (op_hash, str)) == NULL)
     {
       as_bad ("Unknown opcode: `%s'", str);
@@ -6397,8 +6397,11 @@
     {
       if (reg)
 	as_bad (_(".REG must use a label"));
-      else
-	as_bad (_(".EQU must use a label"));
+      else {
+	/* Try gas' standard ".equ X,Y" pseudo opcode.  */
+      	s_set(0);
+	return;
+      }
     }
 
   pa_undefine_label ();
 
Index: doc/as.texinfo
===================================================================
RCS file: /cvs/src/src/gas/doc/as.texinfo,v
retrieving revision 1.155
diff -u -r1.155 as.texinfo
--- doc/as.texinfo	3 Nov 2006 07:29:37 -0000	1.155
+++ doc/as.texinfo	2 Dec 2006 15:10:56 -0000
@@ -4368,8 +4368,8 @@
 It is synonymous with @samp{.set}; see @ref{Set,,@code{.set}}.
 
 @ifset HPPA
-The syntax for @code{equ} on the HPPA is 
-@samp{@var{symbol} .equ @var{expression}}.
+On HPPA the following syntax may be used alternatively:
+@samp{@var{symbol:} .equ @var{expression}}
 @end ifset
 
 @ifset Z80
@@ -5671,8 +5671,8 @@
 file is the last value stored into it.
 
 @ifset HPPA
-The syntax for @code{set} on the HPPA is
-@samp{@var{symbol} .set @var{expression}}.
+Alternatively the syntax for @code{set} on the HPPA is
+@samp{@var{symbol:} .set @var{expression}}.
 @end ifset
 
 @ifset Z80
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] [PATCH] hppa-linux-gas binutils patch

[Helge Deller]

hppa-linux-gnu-gas only allows one type of ".equ" pseudo-op syntax:
symbol:		.equ value

The following patch allows hppa-gas to understand
			.equ symbol,value
as well, which seems to be pretty standard for other gas-targets as well.

I didn't found any problems yet with this patch, and it allows even the 
src/binutils/testsuite/binutils-all/localize-hidden-1.s
gas test  to compile.

Comments ?
If OK, would somebody with write-access to binutils submit it upstream ?

Helge

Index: gas/config/tc-hppa.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-hppa.c,v
retrieving revision 1.133
diff -u -r1.133 tc-hppa.c
--- gas/config/tc-hppa.c	30 Oct 2006 01:09:18 -0000	1.133
+++ gas/config/tc-hppa.c	23 Nov 2006 21:32:49 -0000
@@ -3262,7 +3262,7 @@
       return;
     }
 
-  /* Look up the opcode in the has table.  */
+  /* Look up the opcode in the hash table.  */
   if ((insn = (struct pa_opcode *) hash_find (op_hash, str)) == NULL)
     {
       as_bad ("Unknown opcode: `%s'", str);
@@ -6397,8 +6397,11 @@
     {
       if (reg)
 	as_bad (_(".REG must use a label"));
-      else
-	as_bad (_(".EQU must use a label"));
+      else {
+	/* Try gas' standard ".equ X,Y" pseudo opcode.  */
+      	s_set(0);
+	return;
+      }
     }
 
   pa_undefine_label ();


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux