Re: [Qemu-devel] [PATCH 2/3] arm: semihosting: Create unsupported call function

[Peter Maydell]

On 27 March 2015 at 16:22, Christopher Covington
<address@hidden> wrote:
> This will allow the print-error-and-exit sequence to be called from a
> second location in a subsequent patch. The type of the nr variable is
> changed from int to uint32_t since I'm unaware of semihosting call
> numbers needing more than 32 bits, even on AArch64. Also generalize
> the wording of the unsupported semihosting call error message so that
> it will make sense on AArch64 as well.
>
> Signed-off-by: Christopher Covington <address@hidden>
> ---
>  target-arm/arm-semi.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/target-arm/arm-semi.c b/target-arm/arm-semi.c
> index a8b83e6..d915123 100644
> --- a/target-arm/arm-semi.c
> +++ b/target-arm/arm-semi.c
> @@ -174,6 +174,13 @@ static void arm_semi_flen_cb(CPUState *cs, target_ulong 
> ret, target_ulong err)
>  #endif
>  }
>
> +static void QEMU_NORETURN unsupported_semihosting(uint32_t nr, CPUState *cs)
> +{
> +        fprintf(stderr, "qemu: Unsupported semihosting call 0x%02x\n", nr);
> +        cpu_dump_state(cs, stderr, fprintf, 0);
> +        abort();
> +}
> +
>  /* Read the input value from the argument block; fail the semihosting
>   * call if the memory read fails.
>   */
> @@ -191,7 +198,7 @@ uint32_t do_arm_semihosting(CPUARMState *env)
>      target_ulong args;
>      target_ulong arg0, arg1, arg2, arg3;
>      char * s;
> -    int nr;
> +    uint32_t nr;
>      uint32_t ret;
>      uint32_t len;
>  #ifdef CONFIG_USER_ONLY
> @@ -561,8 +568,6 @@ uint32_t do_arm_semihosting(CPUARMState *env)
>          gdb_exit(env, ret);
>          exit(ret);
>      default:
> -        fprintf(stderr, "qemu: Unsupported SemiHosting SWI 0x%02x\n", nr);
> -        cpu_dump_state(cs, stderr, fprintf, 0);
> -        abort();
> +        unsupported_semihosting(nr, cs);
>      }
>  }
> --
> 1.9.1

OK, I guess, though I think the need to call from multiple places
goes away as soon as we've implemented all the calls, so I would
personally just have implemented them all...

Reviewed-by: Peter Maydell <address@hidden>

thanks
-- PMM