Commit Graph

5 Commits

Author SHA1 Message Date
58fa4c59cc sal/bochs: fix handling of unmapped memory
Up to now, BochsMemory::isMapped() always returned true in 32-bit protected
mode with a 4GB linear address space (as used by, e.g., eCos), even for
addresses greater than the configured memory size.  This led to lots of
bogus memory dereferences in the (extended) tracing plugin.

This change (a follow-up to commit 5171645) additionally checks the return
value of getHostMemAddr(), and announces BX_RW (read/write access) instead
of BX_READ as the intended type of memory access.  In the aforementioned
scenario, memory addresses greater than the memory size are now correctly
detected as "not mapped".

Change-Id: Ic2fa7554c869cb90191164535a601bae4dbb49b6
2014-02-17 23:24:16 +01:00
4cb97a7fa5 formatting, typos, comments, details
Change-Id: Iae5f1acb653a694622e9ac2bad93efcfca588f3a
2014-01-22 13:08:13 +01:00
5171645d9a plugin/tracing: fix extended trace on umapped memory areas
When a register in the extended trace was dereferenced and the value
was smaller than the memory pool size, but the address was not mapped
an assertion occured and the tracing plugin terminated the
simulator. Now the dereferenced memory address is checked for being
mapped and not being smaller than the memory pool.

Change-Id: I9ac954988ef860969679f9f360814c5e4b66f473
2013-10-28 15:09:35 +01:00
hsc
4f18dd945e MemoryController: guestToHost should not be part of the abstract iface
Not all backends have their memory mapped to a Fail*-accessible address.
Especially hardware targets can only be accessed indirectly.

git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1611 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
2012-09-11 17:10:08 +00:00
2575604b41 Fail* directories reorganized, Code-cleanup (-> coding-style), Typos+comments fixed.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1321 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
2012-06-08 20:09:43 +00:00