96df6bedb7
Until now, the only reason a macroop would be left was because it ended at a microop marked as the last microop. In O3 with branch prediction, it's possible for the branch predictor to have entries which originally came from different instructions which happened to have the same RIP. This could theoretically happen in many ways, but it was encountered specifically when different programs in different address spaces ran one after the other in X86_FS. What would happen in that case was that the macroop would continue to be looped over and microops fetched from it until it reached the last microop even though the macropc had moved out from under it. If things lined up properly, this could mean that the end bytes of an instruction actually fell into the instruction sized block of memory after the one in the predecoder. The fetch loop implicitly assumes that the last instruction sized chunk of memory processed was the last one needed for the instruction it just finished executing. It would then tell the predecoder to move to an offset within the bytes it was given that is larger than those bytes, and that would trip an assert in the x86 predecoder. This change fixes this problem by making fetch stop processing the current macroop if the address it should be fetching from changed when the PC is updated. That happens when the last microop was reached because the instruction handled it properly, and it also catches the case where the branch predictor makes fetch do a macro level branch when it shouldn't. The check of isLastMicroop is retained because otherwise, a macroop that branches back to itself would act like a single, long macroop instead of multiple instances of the same microop. There may be situations (which may turn out to be purely hypothetical) where that matters. This also fixes a relatively minor issue where the curMacroop variable would be set to NULL immediately after seeing that a microop was the last one before curMacroop was used to build the dyninst. The traceData structure would have a NULL pointer to the macroop for that microop. |
||
|---|---|---|
| build_opts | ||
| configs | ||
| ext | ||
| src | ||
| system | ||
| tests | ||
| util | ||
| .hgignore | ||
| .hgtags | ||
| COPYING | ||
| LICENSE | ||
| README | ||
| SConstruct | ||
This is the M5 simulator. For detailed information about building the simulator and getting started please refer to http://www.m5sim.org. Specific pages of interest are: http://www.m5sim.org/wiki/index.php/Compiling_M5 http://www.m5sim.org/wiki/index.php/Running_M5 Short version: 1. If you don't have SCons version 0.98.1 or newer, get it from http://wwww.scons.org. 2. If you don't have SWIG version 1.3.31 or newer, get it from http://wwww.swig.org. 3. Make sure you also have gcc version 3.4.6 or newer, Python 2.4 or newer (the dev version with header files), zlib, and the m4 preprocessor. 4. In this directory, type 'scons build/ALPHA_SE/tests/debug/quick'. This will build the debug version of the m5 binary (m5.debug) for the Alpha syscall emulation target, and run the quick regression tests on it. If you have questions, please send mail to m5-users@m5sim.org WHAT'S INCLUDED (AND NOT) ------------------------- The basic source release includes these subdirectories: - m5: - configs: simulation configuration scripts - ext: less-common external packages needed to build m5 - src: source code of the m5 simulator - system: source for some optional system software for simulated systems - tests: regression tests - util: useful utility programs and files To run full-system simulations, you will need compiled system firmware (console and PALcode for Alpha), kernel binaries and one or more disk images. These files for Alpha are collected in a separate archive, m5_system.tar.bz2. This file can he downloaded separately. Depending on the ISA used, M5 may support Linux 2.4/2.6, FreeBSD, and the proprietary Compaq/HP Tru64 version of Unix. We are able to distribute Linux and FreeBSD bootdisks, but we are unable to distribute bootable disk images of Tru64 Unix. If you have a Tru64 license and are interested in obtaining disk images, contact us at m5-users@m5sim.org