[RFC] handling of forward references in expressions

[RFC] handling of forward references in expressions

[Jan Beulich]

I ran into a problem with code that I was able to simplify to

	.text
T0:

	.data
D1:
	.long T0 + (D2 - D1)
	.long X0 + (D2 - D1)
D2:
	.long T0 + (D2 - D1)

Here, the first of the three expressions triggers "operation combines
symbols in different segments", but the second and third don't. This
clearly is wrong - either all or none of them should work. The problem
is that expr() treats the result of (D2 - D1), when D2 isn't defined
yet, as living in the section of D1 rather than in expr_section (and
similarly for operations other than subtraction). I was about to submit
the following patch, when I found that a few targets can't deal with
expressions in expr_section. My question hence is - can someone see
another solution to the original problem, or do I need to go through all
affected targets and find where they make those incorrect assumptions?

Thanks, Jan

--- 2006-07-31/gas/expr.c	2006-07-31 15:54:13.000000000 +0200
+++ 2006-07-31/gas/expr.c	2006-07-31 16:17:55.000000000 +0200
@@ -1839,7 +1839,11 @@ expr (int rankarg,		/* Larger # is
highe
 		  retval = absolute_section;
 		  rightseg = absolute_section;
 		}
+	      else
+		retval = expr_section;
 	    }
+	  else
+	    retval = expr_section;
 	}
       else
 	{
@@ -1849,13 +1853,16 @@ expr (int rankarg,		/* Larger # is
highe
 	  resultP->X_op = op_left;
 	  resultP->X_add_number = 0;
 	  resultP->X_unsigned = 1;
+	  retval = expr_section;
 	}
 
       if (retval != rightseg)
 	{
 	  if (! SEG_NORMAL (retval))
 	    {
-	      if (retval != undefined_section || SEG_NORMAL (rightseg))
+	      if (retval == expr_section)
+		;
+	      else if (retval != undefined_section || SEG_NORMAL
(rightseg))
 		retval = rightseg;
 	    }
 	  else if (SEG_NORMAL (rightseg)

Re: [RFC] handling of forward references in expressions

[Erik Christiansen]

On Tue, Aug 01, 2006 at 11:07:21AM +0200, Jan Beulich wrote:
> I was about to submit the following patch, when I found that a few
> targets can't deal with expressions in expr_section. My question hence
> is - can someone see another solution to the original problem, or do I
> need to go through all affected targets and find where they make those
> incorrect assumptions?

Jan,

Back in 2004, we encountered similar label-arithmetic problems on the
avr port. At
http://lists.gnu.org/archive/html/avr-gcc-list/2003-09/msg00065.html
there are two examples and the beginnings of a code diagnosis. I chased
it from gas/config/tc-avr.c to the gas-generic expr.c file, before my
gumboots filled with mud.

Klaus Rudolph's very useful partial fix appears in
http://lists.gnu.org/archive/html/avr-gcc-list/2004-11/msg00209.html,
but that's avr-specific.

If you find a way to handle generic assembler arithmetic generically, it
would be cause for celebration and gratitude.

Erik

Re: [RFC] handling of forward references in expressions

[Nick Clifton]

Hi Jan,

> I was about to submit
> the following patch, when I found that a few targets can't deal with
> expressions in expr_section. My question hence is - can someone see
> another solution to the original problem, or do I need to go through all
> affected targets and find where they make those incorrect assumptions?

I think that you (or rather we) do need to go through all the affected 
targets and fix them.  Sorry. :-(

Cheers
   Nick

Re: [RFC] handling of forward references in expressions

[Jan Beulich]

Nick,

>> I was about to submit
>> the following patch, when I found that a few targets can't deal with
>> expressions in expr_section. My question hence is - can someone see
>> another solution to the original problem, or do I need to go through all
>> affected targets and find where they make those incorrect assumptions?
>
>I think that you (or rather we)

Does that mean you'd accept a patch that breaks (i.e. results in additional
testsuite failures) two or three targets...

> do need to go through all the affected 
>targets and fix them.  Sorry. :-(

... or is it really meant to say I should (try to) fix targets I don't even have
the slightest knowledge about?

Jan

Re: [RFC] handling of forward references in expressions

[Nick Clifton]

Hi Jan,

>>> another solution to the original problem, or do I need to go through all
>>> affected targets and find where they make those incorrect assumptions?
>> I think that you (or rather we)
> 
> Does that mean you'd accept a patch that breaks (i.e. results in additional
> testsuite failures) two or three targets...

Hmm, tell me which targets first...

>> do need to go through all the affected 
>> targets and fix them.  Sorry. :-(
> 
> ... or is it really meant to say I should (try to) fix targets I don't even have
> the slightest knowledge about?

No, but if you can give an outline of what needs to be fixed, I am 
willing to have a go at repairing the broken targets.  Fixing one such 
target yourself and showing me^H^Hthe list how you did it would also be 
very helpful.

Cheers
   Nick

Re: [RFC] handling of forward references in expressions

[Jan Beulich]

>>>> another solution to the original problem, or do I need to go through all
>>>> affected targets and find where they make those incorrect assumptions?
>>> I think that you (or rather we)
>> 
>> Does that mean you'd accept a patch that breaks (i.e. results in additional
>> testsuite failures) two or three targets...
>
>Hmm, tell me which targets first...

The ones my cross-target testing found (meaning this list may be incomplete) were
- hppa64-unknown-linux-gnu (3 failed tests, all apparently for the same reason)
- hppa-unknown-linux-gnu (likewise)
- i586-pc-aout (1 failed test)

>>> do need to go through all the affected 
>>> targets and fix them.  Sorry. :-(
>> 
>> ... or is it really meant to say I should (try to) fix targets I don't even have
>> the slightest knowledge about?
>
>No, but if you can give an outline of what needs to be fixed, I am 
>willing to have a go at repairing the broken targets.  Fixing one such 
>target yourself and showing me^H^Hthe list how you did it would also be 
>very helpful.

I'll try to, but it'll be a while until I'll have some spare cycles to turn to this.

Jan