On 12 March 2014 14:12,  <[email protected]> wrote:
> From: Alex BennĂ©e <[email protected]>
>
> There are times the tcg aborts with a fatal but terse error which isn't
> overly helpful. This adds an alternative macro that can be used to show
> a little more helper information when an abort occurs.
>
> diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c
> index f832282..1a6c565 100644
> --- a/tcg/i386/tcg-target.c
> +++ b/tcg/i386/tcg-target.c
> @@ -1342,7 +1342,7 @@ static void tcg_out_qemu_ld_slow_path(TCGContext *s, 
> TCGLabelQemuLdst *l)
>          }
>          break;
>      default:
> -        tcg_abort();
> +        tcg_abort_dbg("bad opc:%x", opc);
>      }
>
>      /* Jump to the code corresponding to next IR of qemu_st */
> @@ -1519,7 +1519,7 @@ static void tcg_out_qemu_ld_direct(TCGContext *s, 
> TCGReg datalo, TCGReg datahi,
>          }
>          break;
>      default:
> -        tcg_abort();
> +        tcg_abort_dbg("bad memop=%x", memop);
>      }
>  }
>
> diff --git a/tcg/optimize.c b/tcg/optimize.c
> index 7777743..ae1a3f8 100644
> --- a/tcg/optimize.c
> +++ b/tcg/optimize.c
> @@ -407,7 +407,7 @@ static bool do_constant_folding_cond_eq(TCGCond c)
>      case TCG_COND_EQ:
>          return 1;
>      default:
> -        tcg_abort();
> +        tcg_abort_dbg("bad condition:%d", c);

This is the wrong place to be diagnosing this. We should be (when
TCG debug is enabled) checking the condition when the tcg_gen_setcond
or tcg_set_brcond function is called, so that you get a useful backtrace
that points directly at the buggy frontend code. I suspect the other
two cases are similar.

thanks
-- PMM

Reply via email to