sim regen preparation

  Regerating sim loses commit 1be79b1ebfad from sim/lm32/cpu.h, a
generated file, so this patch move those declarations to
sim/lm32/sim-main.h.

OK to apply?
  

>>>>> "Alan" == Alan Modra via Gdb-patches <gdb-patches@sourceware.org> writes:

Alan> Regerating sim loses commit 1be79b1ebfad from sim/lm32/cpu.h, a
Alan> generated file, so this patch move those declarations to
Alan> sim/lm32/sim-main.h.

In other spots in gdb we stick a read-only header on generated files to
avoid this sort of error, like:

/* THIS FILE IS GENERATED -*- buffer-read-only: t -*- */
/* vi:set ro: */

Pity cgen doesn't do this.

Alan> OK to apply?

I don't mind the patch at all but I wonder why cgen generates calls to
these functions but not declarations for them; whereas for other
functions (e.g., "lm32bf_h_pc_get") it does generate the declarations.

Tom
  

On Mon, Aug 14, 2023 at 10:26:12AM -0600, Tom Tromey wrote:
> >>>>> "Alan" == Alan Modra via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> Alan> Regerating sim loses commit 1be79b1ebfad from sim/lm32/cpu.h, a
> Alan> generated file, so this patch move those declarations to
> Alan> sim/lm32/sim-main.h.
> 
> In other spots in gdb we stick a read-only header on generated files to
> avoid this sort of error, like:
> 
> /* THIS FILE IS GENERATED -*- buffer-read-only: t -*- */
> /* vi:set ro: */
> 
> Pity cgen doesn't do this.

Yes, that would be nice.  Along with a whole lot of other things.  :)

> Alan> OK to apply?
> 
> I don't mind the patch at all but I wonder why cgen generates calls to
> these functions but not declarations for them; whereas for other
> functions (e.g., "lm32bf_h_pc_get") it does generate the declarations.

I'm not curious enough to dive down that rabbit hole, sorry.  The sim
patches I posted were enough for me to regen and run the testsuite, so
that eg. cpu/ patches can be regression tested on sim targets.  I also
looked at regenerated files in enough detail to convince myself that
the changes, in particular to iq2000, were reasonable.  

Note that people might have thought they were testing sim, but "make
check" in sim doesn't do much unless you set up site-sim-config.exp,
or have a lot of AS_FOR_TARGET_$arch, LD_FOR_TARGET_$arch and
CC_FOR_TARGET_$arch in your environment.  Also, linker warnings render
many of the tests "UNTESTED".  Only the latter is fixed, and of course
only for current warnings.
  

Alan Modra via Gdb-patches <gdb-patches@sourceware.org> writes:

> On Mon, Aug 14, 2023 at 10:26:12AM -0600, Tom Tromey wrote:
> [...]
>
> Note that people might have thought they were testing sim, but "make
> check" in sim doesn't do much unless you set up site-sim-config.exp,
> or have a lot of AS_FOR_TARGET_$arch, LD_FOR_TARGET_$arch and
> CC_FOR_TARGET_$arch in your environment.  Also, linker warnings render
> many of the tests "UNTESTED".  Only the latter is fixed, and of course
> only for current warnings.

This sounds like something we should probably dump into the wiki at some
point.
  

On Wed, Aug 16, 2023 at 04:51:13AM +0100, Sam James wrote:
> 
> Alan Modra via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> > On Mon, Aug 14, 2023 at 10:26:12AM -0600, Tom Tromey wrote:
> > [...]
> >
> > Note that people might have thought they were testing sim, but "make
> > check" in sim doesn't do much unless you set up site-sim-config.exp,
> > or have a lot of AS_FOR_TARGET_$arch, LD_FOR_TARGET_$arch and
> > CC_FOR_TARGET_$arch in your environment.  Also, linker warnings render
> > many of the tests "UNTESTED".  Only the latter is fixed, and of course
> > only for current warnings.
> 
> This sounds like something we should probably dump into the wiki at some
> point.

And to clarify a little, my comment applies to --enable-targets=all.
If you are building a specific sim, eg. --target=frv-elf, then the sim
test harness will look for frv-elf-as, frv-elf-ld and use those if
found on $PATH.

BTW, I found the commit responsible for those 155 frv fails.  Fixed as
follows.  I'll commit as obvious tomorrow unless someone nacks it.

----
Re: sim frv: Add a missing return value for frvbf_check_acc_range.

Commit f00b50d057 went the wrong way.  As the comment says this
function is only applicable to fr550.  If not fr550 return 1,
meaning we don't have acc restrictions.

diff --git a/sim/frv/traps.c b/sim/frv/traps.c
index dda066faec3..aee1f0e741a 100644
--- a/sim/frv/traps.c
+++ b/sim/frv/traps.c
@@ -747,7 +747,7 @@ frvbf_check_acc_range (SIM_CPU *current_cpu, SI regno)
   /* Only applicable to fr550 */
   SIM_DESC sd = CPU_STATE (current_cpu);
   if (STATE_ARCHITECTURE (sd)->mach != bfd_mach_fr550)
-    return 0;
+    return 1;
 
   /* On the fr550, media insns in slots 0 and 2 can only access
      accumulators acc0-acc3. Insns in slots 1 and 3 can only access
  

>> I don't mind the patch at all but I wonder why cgen generates calls to
>> these functions but not declarations for them; whereas for other
>> functions (e.g., "lm32bf_h_pc_get") it does generate the declarations.

Alan> I'm not curious enough to dive down that rabbit hole, sorry.

Yeah, makes sense -- me neither.
I see now that cgen doesn't even seem to have bug tracking.

Your patch is OK.

Alan> Note that people might have thought they were testing sim

I think maybe only Mike Frysinger does this.
I'm not sure.

Tom