diff options
author | Ron Dreslinski <rdreslin@umich.edu> | 2006-02-15 22:05:23 -0500 |
---|---|---|
committer | Ron Dreslinski <rdreslin@umich.edu> | 2006-02-15 22:05:23 -0500 |
commit | d142788172ee79e6e67fc8510940c884807305ad (patch) | |
tree | d1c665421357acae6f17cedc4168789f1913f6b1 /RELEASE_NOTES | |
parent | b8a2d1e5c78eac41125a0be0bc2b5d5fe4714684 (diff) | |
download | gem5-d142788172ee79e6e67fc8510940c884807305ad.tar.xz |
More compilation fixes.
Should we add a proxy_port that does the v->p address translation?
Should the proxy port return a fault on translation errors, if we add one?
arch/alpha/alpha_linux_process.cc:
Syscalls use a memPort through the CPU now instead of a xc functional memory.
cpu/base.hh:
Add a pointer to the memPort syscalls will use. Should this be a proxy_port that does address translation?
cpu/exec_context.cc:
cpu/exec_context.hh:
Remove functional memory from the exec context
cpu/simple/cpu.cc:
Set the memPort to be used as the syscall port as the dcache port
sim/syscall_emul.cc:
sim/syscall_emul.hh:
Syscalls use a memPort through the CPU now instead of a xc functional memory.
Also, fix the fact that readStringFunctional doesn't return a fault... should proxy_port handle this because it is doing the translation?
--HG--
extra : convert_revision : 1f65318c6594301a75dc4dc0c99fdd436b094a7f
Diffstat (limited to 'RELEASE_NOTES')
0 files changed, 0 insertions, 0 deletions