public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
* Re: [RFA] Patch for cgen_rtx_error()
       [not found] <20001007215114.D31946@redhat.com>
@ 2000-10-08 14:32 ` Ben Elliston
  2000-10-26 19:25   ` Doug Evans
  0 siblings, 1 reply; 3+ messages in thread
From: Ben Elliston @ 2000-10-08 14:32 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: gdb-patches, cgen development

fche wrote:

   On Sun, Oct 08, 2000 at 11:38:00AM +1100, Ben Elliston wrote:

   > +/* Emit an error message from CGEN RTL.  */
   > +
   > +void
   > +cgen_rtx_error (SIM_CPU *cpu, const char * fmt, ...)
   > +{
   > +  va_list ap;
   > +  va_start(ap, fmt);
   > +  sim_io_printf (CPU_STATE (cpu), fmt, ap);
   > +  va_end(ap);
   > +  sim_io_printf (CPU_STATE (cpu), "\n");
   > +}
   
   Rather than just print the given message (is it really a varargs
   function?), it would be good to do a sim_engine_halt() there too.
   
Upon further inspection, it seems that the CGEN `error' rtx accepts only a
single argument, so this function need not accept varargs.  Right, Doug?

Without making assumptions about the architecture of any given port, what
are you proposing that I pass for the `pc' argument to sim_engine_halt?  
It's wrong to assume that GET_H_PC() and friends will be present.

Ben

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFA] Patch for cgen_rtx_error()
  2000-10-08 14:32 ` [RFA] Patch for cgen_rtx_error() Ben Elliston
@ 2000-10-26 19:25   ` Doug Evans
  2000-10-29 23:27     ` Ben Elliston
  0 siblings, 1 reply; 3+ messages in thread
From: Doug Evans @ 2000-10-26 19:25 UTC (permalink / raw)
  To: Ben Elliston; +Cc: Frank Ch. Eigler, gdb-patches, cgen development

Ben Elliston writes:
 > fche wrote:
 > 
 >    On Sun, Oct 08, 2000 at 11:38:00AM +1100, Ben Elliston wrote:
 > 
 >    > +/* Emit an error message from CGEN RTL.  */
 >    > +
 >    > +void
 >    > +cgen_rtx_error (SIM_CPU *cpu, const char * fmt, ...)
 >    > +{
 >    > +  va_list ap;
 >    > +  va_start(ap, fmt);
 >    > +  sim_io_printf (CPU_STATE (cpu), fmt, ap);
 >    > +  va_end(ap);
 >    > +  sim_io_printf (CPU_STATE (cpu), "\n");
 >    > +}
 >    
 >    Rather than just print the given message (is it really a varargs
 >    function?), it would be good to do a sim_engine_halt() there too.
 >    
 > Upon further inspection, it seems that the CGEN `error' rtx accepts only a
 > single argument, so this function need not accept varargs.  Right, Doug?

Can't remember if I've replied to this.

Leaving it as a varargs fn seems ok to me.
[I don't feel like being anally correct on this one.
Maybe the `error' rtx will be varargs some day.]

 > Without making assumptions about the architecture of any given port, what
 > are you proposing that I pass for the `pc' argument to sim_engine_halt?  
 > It's wrong to assume that GET_H_PC() and friends will be present.

Maybe the `error' rtx should pass `pc' as an argument.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFA] Patch for cgen_rtx_error()
  2000-10-26 19:25   ` Doug Evans
@ 2000-10-29 23:27     ` Ben Elliston
  0 siblings, 0 replies; 3+ messages in thread
From: Ben Elliston @ 2000-10-29 23:27 UTC (permalink / raw)
  To: Doug Evans; +Cc: Frank Ch. Eigler, cgen development

   Leaving it as a varargs fn seems ok to me. [I don't feel like being
   anally correct on this one. Maybe the `error' rtx will be varargs some
   day.]

I believe I followed fche's suggestion and made the function take a single
char * argument.  If we discover this is insufficient, we can easily change
it down the track (when the `error' rtx is modified).

Ben

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-10-29 23:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20001007215114.D31946@redhat.com>
2000-10-08 14:32 ` [RFA] Patch for cgen_rtx_error() Ben Elliston
2000-10-26 19:25   ` Doug Evans
2000-10-29 23:27     ` Ben Elliston

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).