Mike Frysinger
891e7fb179
The sim-events code jumps through some hoops to avoid using 64bit math to manage the current time. One fundamental assumption here is that by constantly scheduling the sim poll event a short time into the future, the 64bit difference will always fall into a signed 32bit value. This does work most of the time, except for when processing the sim poll event itself. Normally, sim_events_process() will dequeue the sim poll event, update the current time (time_from_event) according to the next pending event, process the sim poll event (which will then requeue the sim poll event), and then continue on. The problem here of course is that the current time is updated in that small window before the sim poll event gets a chance to reschedule itself. So if the 64bit difference between the current time and the next event does not fit into the signed 32bit value, time_from_event overflows, and the internal assert at the end of update_time_from_event() triggers. Since attempts at tweaking sim_events_process() logic introduced other subtle bugs (due to tangled assumptions between most pieces of the sim time keeping code), change the time_from_event to a real 64bit value. Tests on my system between a 32bit ELF and a 64bit ELF show no practical difference (it's all lost in the system noise). Basically, I booted a Linux kernel to userspace and then paniced it; this gave me a constant sample size of about 18 million insns. This was noticed when simulating Blackfin Das U-Boot. The simulated core timer is given the max unsigned timeout value possible on a 32bit processor (0xffffffff). This timeout value is used directly to schedule a hw event in the sim future (the IRQ firing). Once the sim poll event is kicked off, the next pending event is the core timer event which is more than 2^31 ticks in the future, and the sim aborts with: sim-events.c:435: assertion failed - current_time == sim_events_time (sd) Signed-off-by: Mike Frysinger <vapier@gentoo.org>
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.