sim regen preparation

sim regen preparation

[Alan Modra]

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?

diff --git a/sim/lm32/cpu.h b/sim/lm32/cpu.h
index d7ce731b423..805f1eb7d30 100644
--- a/sim/lm32/cpu.h
+++ b/sim/lm32/cpu.h
@@ -163,17 +163,6 @@ struct scache {
   struct argbuf argbuf;
 };
 
-/* From traps.c.  */
-extern USI lm32bf_b_insn (SIM_CPU * current_cpu, USI r0, USI f_r0);
-extern USI lm32bf_divu_insn (SIM_CPU * current_cpu, IADDR pc, USI r0, USI r1, USI r2);
-extern USI lm32bf_modu_insn (SIM_CPU * current_cpu, IADDR pc, USI r0, USI r1, USI r2);
-extern void lm32bf_wcsr_insn (SIM_CPU * current_cpu, USI f_csr, USI r1);
-extern USI lm32bf_break_insn (SIM_CPU * current_cpu, IADDR pc);
-extern USI lm32bf_scall_insn (SIM_CPU * current_cpu, IADDR pc);
-
-/* From user.c.  */
-extern UINT lm32bf_user_insn (SIM_CPU * current_cpu, INT r0, INT r1, UINT imm);
-
 /* Macros to simplify extraction, reading and semantic code.
    These define and assign the local vars that contain the insn's fields.  */
 
diff --git a/sim/lm32/sim-main.h b/sim/lm32/sim-main.h
index 82e81988ce5..e0e967c4233 100644
--- a/sim/lm32/sim-main.h
+++ b/sim/lm32/sim-main.h
@@ -56,4 +56,15 @@ extern SIM_CORE_SIGNAL_FN lm32_core_signal;
 lm32_core_signal ((SD), (CPU), (CIA), (MAP), (NR_BYTES), (ADDR), \
 		  (TRANSFER), (ERROR))
 
+/* From traps.c.  */
+extern USI lm32bf_b_insn (SIM_CPU * current_cpu, USI r0, USI f_r0);
+extern USI lm32bf_divu_insn (SIM_CPU * current_cpu, IADDR pc, USI r0, USI r1, USI r2);
+extern USI lm32bf_modu_insn (SIM_CPU * current_cpu, IADDR pc, USI r0, USI r1, USI r2);
+extern void lm32bf_wcsr_insn (SIM_CPU * current_cpu, USI f_csr, USI r1);
+extern USI lm32bf_break_insn (SIM_CPU * current_cpu, IADDR pc);
+extern USI lm32bf_scall_insn (SIM_CPU * current_cpu, IADDR pc);
+
+/* From user.c.  */
+extern UINT lm32bf_user_insn (SIM_CPU * current_cpu, INT r0, INT r1, UINT imm);
+
 #endif /* SIM_MAIN_H */

-- 
Alan Modra
Australia Development Lab, IBM

Re: sim regen preparation

[Tom Tromey]

>>>>> "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

Re: sim regen preparation

[Alan Modra]

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
Australia Development Lab, IBM

Re: sim regen preparation

[Sam James]

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.

Re: sim regen preparation

[Alan Modra]

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

-- 
Alan Modra
Australia Development Lab, IBM

Re: sim regen preparation

[Tom Tromey]

>> 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