Commit Graph

74 Commits

Author SHA1 Message Date
Bryce Denney
3075cb34ed - remove comment that I was using when debugging control-C 2001-09-27 23:50:48 +00:00
Bryce Denney
198f783f8b - my speed boost changes to main.cc and cpu.cc on June 5 were an improvement
in performance, but I did not check the debugger carefully enough while
  testing them.  Part of the performance gain in main.cc revision 1.33 and
  cpu.cc revision 1.9 was to allow bochs to stay in the cpu loop forever
  in a single processor simulation.  (In a multiprocessor simulation it must
  quit the loop periodically to give the other procs a chance to simulate
  too.  Cooperative multiprocessing?)  In the process, I restored calls
  to BX_TICK in the cpu loop for 1-proc simulation only, and removed them
  from the outer loop.  (See main.cc, since it was done right.)  However
  I never made the equivalent change in the debugger code, so in the
  debugger, there were ticks coming from the cpu loop and then an
  equivalent number of ticks coming from the debugger code just outside
  the cpu loop.  The result was, of course, that simulation time went
  at 2x the correct rate.  This simulation time speedup was made even
  worse because the continue loop in the debugger would increment ticks
  by one quantum (5 at the time) no matter how many instructions had
  actually been executed.  So in trace mode in particular, the way it was
  implemented before today, cpu loop would run only one instruction at
  a time and the simulation time would get incremented 1+5=6 times!  One
  tick from the cpu loop, then 5 erroneous ticks from the continue loop.
  Anyway, much of this nonsense should be fixed now.  For uniprocessor
  simulations, only the cpu loop does ticks (for best performance).  For
  multiprocessor simulations, the cpu loop exits after one quantum and
  the code that calls the cpu loop gets to increment ticks instead.
2001-09-27 23:08:30 +00:00
Bryce Denney
9a1364b1f9 - apply patches/patch.consistent2b. Description:
> This patch fixes a number of debugger problems.
>   - with trace-on, simulation time would pass 5x faster than usual, so
>     interrupts and other timed events would happen at different times
>   - with trace-on, breakpoints were ignored
>   - with trace-on, control-C would not stop the processor and return to the
>     debugger.
>
> This patch changes the execution quantum for the debugger to 1, which means
> that cpu_loop is asked to do one instruction at a time.  This may cause
> bochs with the debugger to be slower than before.
>
> I haven't tested without the debugger yet, so I don't know if the timing
> of events matches or not.
2001-09-27 14:19:38 +00:00
Bryce Denney
69ca4e2a9d - change "long long" to Bit64u, several times
- clean up declarations of "int i" in bx_dbg_watch
2001-09-24 00:42:00 +00:00
Bryce Denney
fd7e7ee86c - added debugger command "info fpu" which prints all FPU registers
in an output format similar to gdb (when you do info all-registers).
  Also, if you do "info all" you get the CPU registers and the FPU
  registers.
- added bx_cpu_c method called fpu_print_regs, which is implemented
  in wmFPUemu_glue.cc
2001-09-15 06:55:14 +00:00
Bryce Denney
b62b7f4bde - use instrumentation macros for
BX_INSTR_START BX_INSTR_STOP BX_INSTR_RESET BX_INSTR_PRINT
  They used to be callback functions, a long time ago.
2001-06-28 19:46:34 +00:00
Bryce Denney
80a7541fed - used grep to search for more instances of new bx_options problems that
I have introduced, and fixed a lot.
2001-06-21 14:56:43 +00:00
Bryce Denney
519d231cd4 - fixed naming problems in debugger introduced by my recent checkins 2001-06-21 01:44:32 +00:00
Bryce Denney
52e14e559d - now that some bx_options in main.cc have changed to bx_param_c, the
bochs debugger needed to be updated in the same way.  Instead of
  using "bx_options.rom.path" as a string, it's now
  bx_options.rom.path->getptr () to get the value of the parameter.
2001-06-18 19:01:49 +00:00
Bryce Denney
073dfe781d - compile with debugger has failed because it continued to call bx_bochs_init
when main.cc no longer had one.  Now compiling with debugger is working
  with the control panel.  To get the control panel, you have to click
  the snapshot button, and to get the debugger, you have to press ^C.
  These should be better integrated (maybe a control panel menu choice
  that jumps into the debugger and a debugger command that starts the
  runtime control panel...)
2001-06-13 13:36:12 +00:00
Bryce Denney
f822257511 - there were cases where BX_APIC_SUPPORT were used and others where
BX_SUPPORT_APIC were used.  To follow the pattern used by other
  names like this, I changed them all to BX_SUPPORT_APIC.
  Thanks to Tom Lindström for chasing this down!
2001-06-12 13:07:43 +00:00
Bryce Denney
8195f1d252 - added debugger command: show "vga" which forces a vga update.
I haven't yet seen a case where this makes a useful difference, but
  it doesn't cause problems either.
2001-06-07 15:40:11 +00:00
Bryce Denney
017691abdc - this is the equivalent of main.cc revision 1.34 2001-06-07 02:21:55 +00:00
Todd T.Fries
2bbb1ef8eb strip '\n' from BX_{INFO,DEBUG,ERROR,PANIC}
don't need it, moved the output of it into the general io functions.
saves space, as well as removes the confusing output if a '\n' is left off
2001-05-30 18:56:02 +00:00
Bryce Denney
f278500be5 - check for null CPU pointer on exit 2001-05-29 14:28:38 +00:00
Bryce Denney
49664f7503 - parts of the SMP merge apparantly broke the debugger and this revision
tries to fix it.  The shortcuts to register names such as AX and DL are
  #defines in cpu/cpu.h, and they are defined in terms of BX_CPU_THIS_PTR.
  When BX_USE_CPU_SMF=1, this works fine.  (This is what bochs used for
  a long time, and nobody used the SMF=0 mode at all.)  To make SMP bochs
  work, I had to get SMF=0 mode working for the CPU so that there could
  be an array of cpus.

  When SMF=0 for the CPU, BX_CPU_THIS_PTR is defined to be "this->" which
  only works within methods of BX_CPU_C.  Code outside of BX_CPU_C must
  reference BX_CPU(num) instead.
- to try to enforce the correct use of AL/AX/DL/etc. shortcuts, they are
  now only #defined when "NEED_CPU_REG_SHORTCUTS" is #defined.  This is
  only done in the cpu/*.cc code.
2001-05-24 18:46:34 +00:00
Bryce Denney
6ed99e0e43 - fix typo (beward/beware) 2001-05-23 08:27:10 +00:00
Bryce Denney
e61d00351f - merged BRANCH-smp-bochs into main branch. For details see comments
in BRANCH-smp-bochs revisions.
- The general task was to make multiple CPU's which communicate
  through their APICs.  So instead of BX_CPU and BX_MEM, we now have
  BX_CPU(x) and BX_MEM(y).  For an SMP simulation you have several
  processors in a shared memory space, so there might be processors
  BX_CPU(0..3) but only one memory space BX_MEM(0).  For cosimulation,
  you could have BX_CPU(0) with BX_MEM(0), then BX_CPU(1) with
  BX_MEM(1).  WARNING: Cosimulation is almost certainly broken by the
  SMP changes.
- to simulate multiple CPUs, you have to give each CPU time to execute
  in turn.  This is currently implemented using debugger guards.  The
  cpu loop steps one CPU for a few instructions, then steps the
  next CPU for a few instructions, etc.
- there is some limited support in the debugger for two CPUs, for
  example printing information from each CPU when single stepping.
2001-05-23 08:16:07 +00:00
Todd T.Fries
bdb89cd364 merge in BRANCH-io-cleanup.
To see the commit logs for this use either cvsweb or
cvs update -r BRANCH-io-cleanup and then 'cvs log' the various files.

In general this provides a generic interface for logging.

logfunctions:: is a class that is inherited by some classes, and also
.   allocated as a standalone global called 'genlog'.  All logging uses
.   one of the ::info(), ::error(), ::ldebug(), ::panic() methods of this
.   class through 'BX_INFO(), BX_ERROR(), BX_DEBUG(), BX_PANIC()' macros
.   respectively.
.
.   An example usage:
.     BX_INFO(("Hello, World!\n"));

iofunctions:: is a class that is allocated once by default, and assigned
as the iofunction of each logfunctions instance.  It is this class that
maintains the file descriptor and other output related code, at this
point using vfprintf().  At some future point, someone may choose to
write a gui 'console' for bochs to which messages would be redirected
simply by assigning a different iofunction class to the various logfunctions
objects.

More cleanup is coming, but this works for now.  If you want to see alot
of debugging output, in main.cc, change onoff[LOGLEV_DEBUG]=0 to =1.

Comments, bugs, flames, to me: todd@fries.net
2001-05-15 14:49:57 +00:00
Bryce Denney
e363f402ca - This implements a solution that lets any GUI take over handling of any
signal.  First, selection of the GUI should cause BX_GUI_SIGHANDLER to
  be defined in config.h.in.  Then, the GUI should define member functions
    Bit32u get_sighandler_mask ();
    void sighandler (int sig);
  The mask function returns a bitfield where one bit corresponds to each
  signal.  For any signal whose bit is set to 1 in the return value of
  get_sighandler_mask, the gui will control that signal.  When the signal
  arrives, bx_gui.sighandler(sig) will be called by bx_signal_handler,
  instead of the default behavior of that signal.
2001-05-08 20:18:04 +00:00
Bryce Denney
a6fef54678 - update copyright dates to 2001 for all mandrake headers
- for bochs files with other header, replaced with current mandrake header
2001-04-10 02:20:02 +00:00
Bryce Denney
96174271f9 - change bx_snprintf back to normal name 2001-04-10 01:57:27 +00:00
Bryce Denney
3adbd8f71b - in bx_dbg_print_string_command there was a zero-length array, which
didn't compile with some compiler.
- put conditional "#if BX_HAVE_HASH_MAP" around code that uses
  <hash_map.h>.
- replace calls to snprintf with bx_snprintf.
- arg1 of bx_dbg_watch is an int, not a Boolean.
2001-04-10 01:45:06 +00:00
cvs
beff63eb32 - entered original Bochs snapshot bochs-2000_0325a.tar.gz from
ftp.bochs.com
2001-04-10 01:04:59 +00:00