Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Nick Clifton <nickc@redhat.com>
Cc: gdb-patches@sourceware.org, dje@sebabeach.org, law@redhat.com
Subject: Re: RFA: m32r sim: Add prototypes for functions that pass/return DI values
Date: Wed, 11 Nov 2020 21:13:11 +0000	[thread overview]
Message-ID: <20201111211311.GM2729@embecosm.com> (raw)
In-Reply-To: <87ft5hhzwo.fsf@redhat.com>

* Nick Clifton <nickc@redhat.com> [2020-11-10 17:42:15 +0000]:

> Hi Doug, Hi Andrew,
> 
>   Jeff Law has tracked down a set of problems with the m32r simulator
>   which turned out to be because the m32rbf_h_accum_get_handler()
>   function returns a DI value, but it was not prototyped.  So callers
>   would assume that it returned an int, and happiness ensued...
> 
>   I am proposing the attached patch as a workaround for the problem.  A
>   proper fix would be to update the scheme files used to generate the
>   cpu headers.  But I am not a scheme programmer, and besides getting
>   cgen to work with modern versions of guile seems to be quite
>   difficult.  So instead the patch adds prototypes into one of the m32r
>   sim header files that is not auto-generated.
> 
>   OK to apply ?
> 
> Cheers
>   Nick
> 
> sim/m32r/ChangeLog
> 2020-11-10  Nick Clifton  <nickc@redhat.com>
> 
> 	* m32r-sim.h (m32rbf_h_accum_get_handler): Always provide a
> 	prototype for this function.
> 	(m32rbf_h_accum_set_handler): Likewise.
> 	(m32r2f_h_accums_get_handler): Prototype.
> 	(m32r2f_h_accums_set_handler): Prototype.
> 
> diff --git a/sim/m32r/m32r-sim.h b/sim/m32r/m32r-sim.h
> index 9f3e270f39..6f9f4610c0 100644
> --- a/sim/m32r/m32r-sim.h
> +++ b/sim/m32r/m32r-sim.h
> @@ -61,10 +61,19 @@ extern void m32rbf_h_psw_set_handler (SIM_CPU *, UQI);
>    XCONCAT2 (WANT_CPU,_h_psw_set_handler) (current_cpu, (val))
>  #endif
>  
> -#ifndef  GET_H_ACCUM
> +/* FIXME: These prototypes are necessary because the cgen generated
> +   cpu.h, cpux.h and cpu2.h headers do not provide them, and functions
> +   which take or return parameters that are larger than an int must be
> +   prototyed in order for them to work correctly.
> +
> +   The correct solution is to fix the code in cgen/sim.scm to generate
> +   prototypes for each of the functions it generates.  */
>  extern DI   m32rbf_h_accum_get_handler (SIM_CPU *);
>  extern void m32rbf_h_accum_set_handler (SIM_CPU *, DI);
> +extern DI   m32r2f_h_accums_get_handler (SIM_CPU *, UINT);
> +extern void m32r2f_h_accums_set_handler (SIM_CPU *, UINT, DI);

It looks like someone already did some of this before, so it seems
hard to argue against it :-)

Feel free to apply.

Thanks,
Andrew



>  
> +#ifndef  GET_H_ACCUM
>  #define GET_H_ACCUM() \
>    XCONCAT2 (WANT_CPU,_h_accum_get_handler) (current_cpu)
>  #define SET_H_ACCUM(val) \
> 

      parent reply	other threads:[~2020-11-11 21:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-10 17:42 Nick Clifton via Gdb-patches
2020-11-10 18:26 ` Simon Marchi
2020-11-11 15:33   ` Nick Clifton via Gdb-patches
2021-01-13  4:35     ` Mike Frysinger via Gdb-patches
2020-11-11 21:13 ` Andrew Burgess [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201111211311.GM2729@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=dje@sebabeach.org \
    --cc=gdb-patches@sourceware.org \
    --cc=law@redhat.com \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox