Use of as_fatal

Use of as_fatal

[Jan Beulich]

As the new 'macros dot' test has uncovered and (assuming the corresponding patch will get approved) 'macros purge' will too for some of the targets mentioned below, there is an issue with using as_fatal in places where the failure doesn't really appear to be fatal. Namely, when just an opcode isn't recognized (as would happen when one tries to reference a macro that isn't defined (yet/anymore), this condition is supposed to be hit. I am therefore wondering if the maintainers of the following targets could shed some light on the reasons why as_fatal is being used in this case by these targets; the outcome will help determine whether the target specific code should be changed or instead the target be excluded from running these tests.

hppa
ns32k
sparc
vax

Additionally a few other targets have problems here because of error message issuing differences; this can be taken into account in the output expectations, but I wonder whether there isn't a goal of having some standarddization in that respect between targets, namely with regard to

- issuing just a single error message for a single source error
- whether (and/or when/how) to re-issue error messages in the listing generation code

Thanks, Jan

Re: Use of as_fatal

[David S. Miller]

On Mon, 18 Apr 2005 15:12:36 +0200
"Jan Beulich" <JBeulich@novell.com> wrote:

> As the new 'macros dot' test has uncovered and (assuming the
> corresponding patch will get approved) 'macros purge' will too for
> some of the targets mentioned below, there is an issue with using
> as_fatal in places where the failure doesn't really appear to be
> fatal. Namely, when just an opcode isn't recognized (as would happen
> when one tries to reference a macro that isn't defined (yet/anymore),
> this condition is supposed to be hit. I am therefore wondering if the
> maintainers of the following targets could shed some light on the
> reasons why as_fatal is being used in this case by these targets; the
> outcome will help determine whether the target specific code should be
> changed or instead the target be excluded from running these tests.

[ please line-wrap your emails in the future, much appreciated... ]

I fixed the as_fatal() which was tripping up the macro dot testcases.
Patch below.

While macro dot appears to be fixes on Sparc, the new macro purge testcase
seems to hang infinitely.  As far as I can tell it is trying to expand macros
over and over for some reason.  I thought initially this was caused
by tc-sparc.c:sparc_ip()'s modification of the string it is given,
yet tests of making sparc_ip() not do this didn't fix the problem.

2005-04-18  David S. Miller  <davem@davemloft.net>

	* config/tc-sparc.c (md_assemble): If sparc_ip gives us a
	NULL insn, exit early.  Remove now spurious NULL checks.
	(sparc_ip): Use as_bad for unknown opcode errors, set *pinsn
	to NULL and exit.

--- config/tc-sparc.c	18 Feb 2005 00:49:03 -0000	1.54
+++ config/tc-sparc.c	18 Apr 2005 20:20:58 -0000
@@ -1304,11 +1304,12 @@ md_assemble (str)
 
   know (str);
   special_case = sparc_ip (str, &insn);
+  if (insn == NULL)
+    return;
 
   /* We warn about attempts to put a floating point branch in a delay slot,
      unless the delay slot has been annulled.  */
-  if (insn != NULL
-      && last_insn != NULL
+  if (last_insn != NULL
       && (insn->flags & F_FBR) != 0
       && (last_insn->flags & F_DELAYED) != 0
       /* ??? This test isn't completely accurate.  We assume anything with
@@ -1321,7 +1322,6 @@ md_assemble (str)
      point instruction and a floating point branch.  We insert one
      automatically, with a warning.  */
   if (max_architecture < SPARC_OPCODE_ARCH_V9
-      && insn != NULL
       && last_insn != NULL
       && (insn->flags & F_FBR) != 0
       && (last_insn->flags & F_FLOAT) != 0)
@@ -1417,7 +1417,9 @@ sparc_ip (str, pinsn)
       break;
 
     default:
-      as_fatal (_("Unknown opcode: `%s'"), str);
+      as_bad (_("Unknown opcode: `%s'"), str);
+      *pinsn = NULL;
+      return special_case;
     }
   insn = (struct sparc_opcode *) hash_find (op_hash, str);
   *pinsn = insn;

Re: Use of as_fatal

[David S. Miller]

On Tue, 19 Apr 2005 08:40:51 +0200
"Jan Beulich" <JBeulich@novell.com> wrote:

[ Please, again, line wrap your emails.  Not doing so makes them
  not so easy to ready.  Thank you for your attention on this matter. ]

> Hmm, that sounds odd. The test expands and purges 26**4 macros, to
> check that the purging reclaims the memory used for the macro
> definition; there's certainly some memory implicitly used elsewhere
> that can't be reclaimed, so it still shows an increasing memory usage
> over the time it runs.

Perhaps I'm just not patient enough...

Indeed after about 56 seconds the test does complete successfully.

But this is on the fastest machine I own, a 1.5GHZ UltraSPARC-IIIi.

I can't imagine this completing within the default testsuite timeout
of 300 seconds on my 300Mhz Ultra-II system for example.  And consider
someone on an m68k machine or similar.

Is it possible to tone down the number of macros the testcase expands
and purges?  Perhaps something like 16**4 or something like that?  It
should still be possible to make sure that the memory is reclaimed,
or another mechanism to detect proper memory reclaiming could be
devised.

Re: Use of as_fatal

[Jan Beulich]

>I fixed the as_fatal() which was tripping up the macro dot testcases.
>Patch below.

Thanks.

>While macro dot appears to be fixes on Sparc, the new macro purge testcase
>seems to hang infinitely.  As far as I can tell it is trying to expand macros
>over and over for some reason.  I thought initially this was caused
>by tc-sparc.c:sparc_ip()'s modification of the string it is given,
>yet tests of making sparc_ip() not do this didn't fix the problem.

Hmm, that sounds odd. The test expands and purges 26**4 macros, to check that the purging reclaims the memory used for the macro definition; there's certainly some memory implicitly used elsewhere that can't be reclaimed, so it still shows an increasing memory usage over the time it runs. On the EM64T system I used to test this, it takes far less than a minute to complete (without the late addition of --hash-size it took several minutes), so I'd expect other systems, unless equipped with very little memory, to be able to cope with this test, too (without the purging, the loss of memory was in the range of gigabytes, so especially on 32-bit boxes it would complete only after a very long time of heavy swapping, if at all). So I guess the question regarding your observation is whether it indeed hangs (which I can't imagine) or just makes very slow progress (and if so, for what reason).

Jan