changeset 931ef19535e0 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=931ef19535e0
description:
LibElf: Build the error management code in libelf.
This change makes some minor changes to get the error management code in
libelf to build on Linux and
changeset 9fb150de362e in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=9fb150de362e
description:
Loader: Handle bad section names when loading an ELF file.
If there's a problem when reading the section names from a supposed ELF
file,
this change
On 06/12/11 16:29, Steve Reinhardt wrote:
On Sun, Jun 12, 2011 at 1:05 AM, Gabe Black gbl...@eecs.umich.edu wrote:
I was thinking about this today, and if we expand the read/write
functions to handle signed types too, we're really just expanding the
arbitrary set of types they can handle, not
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed.
*
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/744/#review1328
---
src/cpu/inorder/resources/bpred_unit.cc
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/611/#review1330
---
This patch has all the functionality we need. Also I really like the
Yes, the token protocol is definitely one of those protocols that prevents us
from tightly coupling the functional access support to the protocols. However,
I don't this issue will result in silently corrupted behavior. Instead, it
seems the result would be an error generated in the
