1. 10 6月, 2019 1 次提交
  2. 19 4月, 2019 1 次提交
    • M
      qom/cpu: Simplify how CPUClass:cpu_dump_state() prints · 90c84c56
      Markus Armbruster 提交于
      CPUClass method dump_statistics() takes an fprintf()-like callback and
      a FILE * to pass to it.  Most callers pass fprintf() and stderr.
      log_cpu_state() passes fprintf() and qemu_log_file.
      hmp_info_registers() passes monitor_fprintf() and the current monitor
      cast to FILE *.  monitor_fprintf() casts it right back, and is
      otherwise identical to monitor_printf().
      
      The callback gets passed around a lot, which is tiresome.  The
      type-punning around monitor_fprintf() is ugly.
      
      Drop the callback, and call qemu_fprintf() instead.  Also gets rid of
      the type-punning, since qemu_fprintf() takes NULL instead of the
      current monitor cast to FILE *.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      Message-Id: <20190417191805.28198-15-armbru@redhat.com>
      90c84c56
  3. 12 11月, 2018 1 次提交
    • P
      linux-user: Don't call gdb_handlesig() before queue_signal() · b10089a1
      Peter Maydell 提交于
      The CPU main-loop routines for linux-user generally
      call gdb_handlesig() when they're about to queue a
      SIGTRAP signal. This is wrong, because queue_signal()
      will cause us to pend a signal, and process_pending_signals()
      will then call gdb_handlesig() itself. So the effect is that
      we notify gdb of the SIGTRAP, and then if gdb says "OK,
      continue with signal X" we will incorrectly notify
      gdb of the signal X as well. We don't do this double-notify
      for anything else, only SIGTRAP.
      
      Remove this unnecessary and incorrect code from all
      the targets except for nios2 (whose main loop is
      doing something different and broken, and will be handled
      in a separate patch).
      
      This bug only manifests if the user responds to the reported
      SIGTRAP using "signal SIGFOO" rather than "continue"; since
      the latter is the overwhelmingly common thing to do after a
      breakpoint most people won't have hit this.
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
      Message-Id: <20181019174958.26616-2-peter.maydell@linaro.org>
      Signed-off-by: NLaurent Vivier <laurent@vivier.eu>
      b10089a1
  4. 30 4月, 2018 2 次提交
  5. 05 2月, 2016 1 次提交
  6. 18 12月, 2015 1 次提交
  7. 11 9月, 2015 1 次提交
  8. 15 3月, 2012 1 次提交
  9. 17 7月, 2009 1 次提交
  10. 06 1月, 2009 1 次提交
  11. 27 10月, 2008 1 次提交