In the x86 decoder, some architectural state (CPU mode, a couple other
things) is used to pick an active decode cache from a hash map of caches.
That state could then be used when decoding instructions since we'd still
always get the same thing for a particular ExtMachInst given a particular
I realize the context for this might not be something everybody is familiar
with. If you need me to explain what this is about more I can do that.
Gabe
On Wed, Feb 4, 2015 at 2:23 PM, Gabe Black gabebl...@google.com wrote:
In the x86 decoder, some architectural state (CPU mode, a couple other
I just noticed that the fxsave and fxrstor implementations Andreas did
(going by the copyright header in the file) incorrectly assume that the CPU
is in 64 bit mode and save XMM8-15 unconditionally. I'll likely put
together a patch to fix that, but I wanted to mention it here so it didn't
slip
to contribute back to
the public code base).
Steve
On Thu, Jan 29, 2015 at 1:38 AM, Gabe Black via gem5-dev
gem5-dev@gem5.org
wrote:
Hi Mike. When we boot Linux on gem5, the simulator acts as the
bootloader.
It unpacks the kernel, provides various tables in memory that would
normally
Hi Mike. When we boot Linux on gem5, the simulator acts as the bootloader.
It unpacks the kernel, provides various tables in memory that would
normally be provided by the BIOS/firmware, does some setup of machine
state, and then jumps to the kernel. On a real system, the components that
get you to
On Jan. 21, 2015, 9:22 p.m., mike upton wrote:
src/arch/x86/process.cc, lines 218-237
http://reviews.gem5.org/r/2557/diff/2/?file=42948#file42948line218
For AMD systems, the sys descriptors need to come first. On intel
systems they need to come second.
I do not know
On Jan. 21, 2015, 9:22 p.m., mike upton wrote:
src/arch/x86/process.cc, lines 218-237
http://reviews.gem5.org/r/2557/diff/2/?file=42948#file42948line218
For AMD systems, the sys descriptors need to come first. On intel
systems they need to come second.
I do not know
It sounds like a bug/race condition in the O3 CPU, which I think you
already knew. You could try moving the suspend call into a fault returned
by the MicroHalt microop instead of the instruction itself. That might
break the race, although it's not really fixing the issue with O3.
Gabe
On Tue,
On Jan. 16, 2015, 11:56 p.m., mike upton wrote:
src/arch/x86/process.cc, lines 212-213
http://reviews.gem5.org/r/2557/diff/2/?file=42948#file42948line212
when limitHigh and limitLow get set by dataSegDesc(), it seems that
limitHigh and limitLow get reversed.
This patch
On Jan. 16, 2015, 11:28 p.m., mike upton wrote:
src/arch/x86/utility.hh, line 219
http://reviews.gem5.org/r/2557/diff/2/?file=42952#file42952line219
Is there a reason the desc.l does not get set for the dataSegDesc()?
code sets p,l,d,g,s.
Yes. The long mode bit only means
On Jan. 16, 2015, 12:44 a.m., mike upton wrote:
src/arch/x86/regs/misc.hh, line 922
http://reviews.gem5.org/r/2557/diff/2/?file=42949#file42949line922
really 32, 0 in the new code?
Yeah, I think that should be 31, 0
- Gabe
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2604/#review5755
---
This will break GDB single stepping.
- Gabe Black
On Jan. 14, 2015,
On Jan. 14, 2015, 8:52 p.m., Gabe Black wrote:
This will break GDB single stepping.
Nikos Nikoleris wrote:
If I undestand correctly, it won't be affected. When set, the GDB single
step schedules the corresponding event at the comInstEventQueue. The
comInstEventQueue services
On Jan. 13, 2015, 10:53 p.m., Andreas Hansson wrote:
I suspect I am the only one annoyed by this...unless someone else feels the
same I will discard the patch.
If this is what I think it is, it can be pretty annoying when running
regressions. The param stuff swamps the console and its
t0 must always return 0, and writes to it must always be ignored (or
overwritten before the next instruction). You're corrupted program counter
might be because you're using physical registers which aren't actually
there, accessing beyond the end of an array and reading/writing something
random.
changeset 469cf1ea40f5 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=469cf1ea40f5
description:
stats: x86: Update stats for the CPUID change.
diffstat:
tests/long/fs/10.linux-boot/ref/x86/linux/pc-o3-timing/config.ini
| 6 +
changeset 04923a93f2b5 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=04923a93f2b5
description:
test: Add a unittest for the BitUnion types.
diffstat:
src/unittest/SConscript |1 +
src/unittest/bituniontest.cc | 182
Unless you're using the KVM CPU or human input (neither should be true for
regressions), gem5 is supposed to be entirely deterministic. If you're
worried about last nights regressions, the x86 problem was because I pushed
a CPUID related change but hadn't generated a stats CL to go with it. While
On Jan. 5, 2015, 10:48 p.m., Andreas Hansson wrote:
Can you explain the sequence of events that result in bad behavior? If
possible (which is not necessarily the case), it would be best to fix this
without adding arbitrary delays.
Andreas Hansson wrote:
The crossbar is processing
On Jan. 6, 2015, 7:21 p.m., Steve Reinhardt wrote:
Can you be more specific about what doesn't work? Do we really need to
back out all of the enabled features?
Also, it would be nice to replace the comments with different comments,
rather than just getting rid of them. If you
changeset 5d119a460f15 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=5d119a460f15
description:
x86: Enable three bits in the FamilyModelStepping ECX CPUID bitfield.
These are for the monitor/mwait instructions, SSSE3, and XSAVE.
diffstat:
changeset e9bc4cde5d8e in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=e9bc4cde5d8e
description:
cpuid, x86: Revert Enabling more features in CPUid
That change enables CPUID bits for features that aren't implemented in
gem5.
If a simulated system
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2595/#review5724
---
src/arch/x86/pagetable_walker.cc
Hey folks. Hopefully you're back from various holidays now. Ali reviewed my
bitunion unit test, but the actual fix still needs to be reviewed, as does
my fix for the circletest uinttest. cprintftest still doesn't compile.
Gabe
On Wed, Dec 24, 2014 at 4:47 PM, Gabe Black gabebl...@google.com
On Jan. 5, 2015, 10:48 p.m., Andreas Hansson wrote:
Can you explain the sequence of events that result in bad behavior? If
possible (which is not necessarily the case), it would be best to fix this
without adding arbitrary delays.
Andreas Hansson wrote:
The crossbar is processing
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2585/
---
(Updated Dec. 26, 2014, 9:32 p.m.)
Review request for Default.
Repository: gem5
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2590/#review5712
---
bump
- Gabe Black
On Dec. 23, 2014, 12:37 a.m., Gabe Black wrote:
I'm still waiting for reviews on my bituion fix, unittest, and my fix
compilation fix for the circletest unittest.
Also the cprintftest unittest still won't compile, unless someone slipped
in a fix while I wasn't looking. I think that's likely from a change
Andreas did changing how varargs are
On Dec. 23, 2014, 10:25 a.m., Andreas Hansson wrote:
Looks fine. Could you mark the issues that are fixed as fixed (or dropped
for that matter)?
Thanks.
I am still not sure if I like the USE_KVM better, or perhaps having a
NullKvm object.
Yeah. There was one other mistake I
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2565/#review5703
---
I added a comment to this review, but since the issue had been marked
I complained about those names a long time ago, and I still think they
aren't very good. quick and long aren't really on the same scale, to
start with. Something can be quick (a rate) and still take a long time.
Medium is very generic and so isn't on a different axis, but since the
others aren't
I mean quick, medium, slow, not quick, medium, fast.
On Mon, Dec 22, 2014 at 12:44 PM, Gabe Black gabebl...@google.com wrote:
I complained about those names a long time ago, and I still think they
aren't very good. quick and long aren't really on the same scale, to
start with. Something can
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2590/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2591/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
On Dec. 18, 2014, 10:39 a.m., Gabe Black wrote:
src/dev/cirrus.hh, line 48
http://reviews.gem5.org/r/2511/diff/6/?file=43227#file43227line48
They probably shouldn't be. I'll fix that.
These default to private, but I'll make that explicit.
- Gabe
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2511/
---
(Updated Dec. 23, 2014, 1:04 a.m.)
Review request for Default.
Repository: gem5
On Dec. 23, 2014, 5:19 a.m., Steve Reinhardt wrote:
Fine with me, assuming that our implementations of those features are
indeed complete.
They aren't, but I think the bits that are missing will trigger warnings.
- Gabe
---
This
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2589/#review5698
---
Ship it!
Ship It!
- Gabe Black
On Dec. 19, 2014, 1:20 p.m., Andreas
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2588/#review5699
---
Ship it!
Ship It!
- Gabe Black
On Dec. 19, 2014, 1:18 p.m., Andreas
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2511/#review5696
---
src/dev/Cirrus.py
http://reviews.gem5.org/r/2511/#comment5087
On Dec. 17, 2014, 1:53 p.m., Andreas Hansson wrote:
src/dev/x86/i8042.hh, line 118
http://reviews.gem5.org/r/2518/diff/2/?file=42731#file42731line118
I know it is not changed, but could you elaborate on the unit?
I'll have to look at it again to figure out what the unit is, but
I tried to upload these patches to review board but it kept giving me this:
abort: The file was not found in the repository (207)
stat: fail
file: src/arch/x86/cpuid.cc
One is a revert of the original CPUID patch, and the second is a new patch
which enables just a few feature bits to make SE
Hi folks. I was just thinking about how that CPUID change caused problems
when running ChromeOS, and it occurred to me that it doesn't matter what
gem5 supports when CPUID is run if the host system doesn't support the
features it claims. To be really safe, when running with KVM, we should
report
Yeah, I'm not sure which way to go. I think broadening the definition of a
pseudo instruction makes sense, but there's a reasonable amount of existing
usage we'd want to update to keep things from being confusing. You might
call the file util_inst? Or if it's in a directory of just instruction
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2583/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2584/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2585/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
I went to add a bitunion unit test, and I found that two of the unittests
don't compile, circletest and cprintftest. I fixed circletest, but
cprintftest still doesn't build.
circletest fix:
http://reviews.gem5.org/r/2583/
bitunion fix:
http://reviews.gem5.org/r/2584/
bitunion unit test:
On Nov. 25, 2014, 10:31 p.m., Nilay Vaish wrote:
What's TLC and CL?
tender loving care and change list
- Gabe
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2519/#review5547
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2511/
---
(Updated Dec. 17, 2014, 7:27 a.m.)
Review request for Default.
Repository: gem5
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2519/
---
(Updated Dec. 17, 2014, 7:35 a.m.)
Review request for Default.
Repository: gem5
On Nov. 25, 2014, 10:23 p.m., Nilay Vaish wrote:
src/dev/x86/i8042.cc, line 418
http://reviews.gem5.org/r/2519/diff/1/?file=42718#file42718line418
We don't need this nack().
I changed the panic to a warn and left the nack in.
On Nov. 25, 2014, 10:23 p.m., Nilay Vaish wrote:
These VNC/KVM changes are still pending:
http://reviews.gem5.org/r/2514/
http://reviews.gem5.org/r/2511/
http://reviews.gem5.org/r/2517/ (marked ship it)
http://reviews.gem5.org/r/2518/
http://reviews.gem5.org/r/2519/
http://reviews.gem5.org/r/2520/ (marked ship it)
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2511/
---
(Updated Dec. 17, 2014, 7:39 a.m.)
Review request for Default.
Repository: gem5
.
On Sun, Dec 14, 2014 at 9:53 PM, Gabe Black via gem5-dev
gem5-dev@gem5.org
wrote:
I just tried running bzip2 approximately like the regressions would but
with the KVM CPU, and it seemed to work just fine. The only thing I
changed
was I hacked se.py to set the cwd to what bzip2
It sounds like from this:
http://www.informit.com/guides/content.aspx?g=cplusplusseqNum=556
and this:
http://stackoverflow.com/questions/10693913/c11-anonymous-union-with-non-trivial-members
it might now be fixable if we're using C++11. Are we?
Gabe
On Fri, Dec 12, 2014 at 12:41 AM, Gabe
] On Behalf Of Gabe
Black
via gem5-dev
Sent: Wednesday, December 10, 2014 1:21 AM
To: gem5 Developer List
Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
Ok, I got SE working too. I'll clean up my patch and send that out
in a bit.
Gabe
On Tue, Dec 9, 2014
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2563/#review5685
---
I didn't see anything that seemed wrong, but I don't know anything about
I tried reverting this change and it fixes the undefined instruction
exceptions I was seeing. It does break KVM in SE mode though, so we
probably shouldn't yank it out entirely. We need to find a minimal version
of that change which makes KVM in SE work without breaking other things.
Gabe
On
Hi folks. This is mostly addressed to people up on fancy new language
features. Back when I implemented the BitUnion stuff, I discovered that
there was an annoying and serious bug which resulted from a limitation of
C++. At the time, I think I saw that the missing feature would become
available in
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2565/#review5683
---
src/arch/arm/decoder.hh
http://reviews.gem5.org/r/2565/#comment5056
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2567/#review5684
---
While it's definitely nice to get these into regular C++ instead of the
Hi Randolf. I'm not familiar with the multiboot patches, but yes, secondary
(AP) CPUs make a brief trip through real mode and 32 bit mode on their way
to 64 bit mode, and we simulate that.
The ELF loader in SE mode predates me, but I've always thought it tried too
hard to identify what was what
On Dec. 10, 2014, 10:30 p.m., mike upton wrote:
There is some issue with AMD platforms. A test that used to run in 30 sec
is not finishing.
mike upton wrote:
hello world passes. SPEC apps hang.
Gabe Black wrote:
Can you identify where it's getting stuck? It could be
Yeah, I was going to say something about that. CPUID shouldn't advertise
features that we don't support. For instance, that change tells CPUID to
say we support AVX, but the decoder has no idea what to do with those
instructions and will trigger an exception if one is executed. I noticed a
bunch
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/
---
(Updated Dec. 10, 2014, 10:11 a.m.)
Review request for Default.
Summary
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5663
---
Ok, now it's for real. Review away.
- Gabe Black
On Dec. 10, 2014,
register (which gets passed to kvm) are the same if with or without
*_EFF_BASE registers set.
Thank you,
Alex
-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black
via gem5-dev
Sent: Wednesday, December 10, 2014 1:21 AM
To: gem5 Developer List
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2558/#review5665
---
Ship it!
Ship It!
- Gabe Black
On Dec. 10, 2014, 5:54 p.m., Ali
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2559/#review5667
---
Ship it!
Ship It!
- Gabe Black
On Dec. 10, 2014, 5:54 p.m., Ali
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2561/#review5666
---
src/sim/insttracer.hh
http://reviews.gem5.org/r/2561/#comment5053
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2562/#review5668
---
Ship it!
Ship It!
- Gabe Black
On Dec. 10, 2014, 5:56 p.m., Ali
On Dec. 10, 2014, 10:30 p.m., mike upton wrote:
There is some issue with AMD platforms. A test that used to run in 30 sec
is not finishing.
mike upton wrote:
hello world passes. SPEC apps hang.
Can you identify where it's getting stuck? It could be there's something wrong
was going on wrong.
--
Nilay
On Mon, 8 Dec 2014, Gabe Black via gem5-dev wrote:
I'm pretty sure entering 64 bit mode is the same between AMD and
Intel CPUs. I vaguely remember there being some subtle page table
difference though, and gem5 is building the page tables in SE mode
(2 weeks ago)
changeset 10554 fe2e2f06a7c8
I saw the hardware reason 0x8021, but did not try to figure what was
going on wrong.
--
Nilay
On Mon, 8 Dec 2014, Gabe Black via gem5-dev wrote:
I'm pretty sure entering 64 bit mode is the same between AMD and Intel
CPUs
.
--
Nilay
On Mon, 8 Dec 2014, Gabe Black via gem5-dev wrote:
I'm pretty sure entering 64 bit mode is the same between AMD and Intel
CPUs. I vaguely remember there being some subtle page table difference
though, and gem5 is building the page tables in SE mode instead
that got
FS working?
Thanks,
Alex
-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black
via gem5-dev
Sent: Tuesday, December 09, 2014 6:07 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
Oh, I see you
that got
FS working?
Thanks,
Alex
-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe
Black via gem5-dev
Sent: Tuesday, December 09, 2014 6:07 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
Oh, I see you
. Could you please share the diffs that got
FS working?
Thanks,
Alex
-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe
Black via gem5-dev
Sent: Tuesday, December 09, 2014 6:07 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] x86 SE kvm
haven't received any attachment to your email. So I don't have your
patch.
Alex
-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black
via gem5-dev
Sent: Tuesday, December 09, 2014 6:42 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] x86 SE
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5659
---
Posted for reference, don't review yet.
- Gabe Black
On Dec. 10,
: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe
Black via gem5-dev
Sent: Tuesday, December 09, 2014 6:42 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
And... it turns out the KVM change wasn't necessary. If you're working
from my
changeset 8fc6e7a835d1 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=8fc6e7a835d1
description:
Let other objects set up memory like regions in a KVM VM.
diffstat:
src/cpu/kvm/vm.cc | 80 --
src/cpu/kvm/vm.hh |
On Dec. 8, 2014, 2:36 p.m., Andreas Hansson wrote:
src/cpu/kvm/vm.cc, line 374
http://reviews.gem5.org/r/2510/diff/2/?file=42734#file42734line374
I think this causes problems with some of the officially supported
compilers. It's just a hunch, but please check.
Gabe Black
On Nov. 19, 2014, 3:33 p.m., Andreas Sandberg wrote:
The change itself makes sense, but I'd really prefer if we could avoid
conditional compilation and use a kvm-agnostic interface to handle device
memory. See my reply in the email thread for RB #2513.
Consider this a ship it if it
via gem5-dev
gem5-dev@gem5.org wrote:
I haven't received any attachment to your email. So I don't have your
patch.
Alex
-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe
Black via gem5-dev
Sent: Tuesday, December 09, 2014 6:42 PM
To: gem5
I'm not an expert either, but I did have problems running KVM in SE mode on
an Intel CPU. I didn't look into it that much, but I think things failed in
the kernel somewhere. What might be happening is that the different vendors
hardware virtualization mechanisms are more or less picky about
On Dec. 8, 2014, 2:36 p.m., Andreas Hansson wrote:
src/cpu/kvm/vm.cc, line 374
http://reviews.gem5.org/r/2510/diff/2/?file=42734#file42734line374
I think this causes problems with some of the officially supported
compilers. It's just a hunch, but please check.
Ugh. Yes, I think
the KVM kernel model will tell about the cause
of failure.
Best regards,
Alex
From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Gabe Black via
gem5-dev [gem5-dev@gem5.org]
Sent: Monday, December 08, 2014 7:08 PM
To: gem5 Developer List
Subject
On Dec. 4, 2014, 4:01 p.m., Steve Reinhardt wrote:
src/base/remote_gdb.hh, line 157
http://reviews.gem5.org/r/2538/diff/1/?file=42808#file42808line157
a comment here like '// size of cache in bytes' would be nice just to
be clear (and since that has changed)
Fixed.
- Gabe
changeset 25ecfc14f73f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=25ecfc14f73f
description:
misc: Make the GDB register cache accessible in various sized chunks.
Not all ISAs have 64 bit sized registers, so it's not always very
convenient
to
changeset 1eec33d2fc52 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=1eec33d2fc52
description:
cpu: Only check for PC events on instruction boundaries.
Only the instruction address is actually checked, so there's no need to
check
repeatedly while
On Dec. 4, 2014, 6:59 p.m., Steve Reinhardt wrote:
src/base/remote_gdb.hh, line 118
http://reviews.gem5.org/r/2540/diff/1/?file=42812#file42812line118
I'd be tempted to rename the other Event class rather than have to
disambiguate here, but I understand if you don't want to be
On Dec. 4, 2014, 6:50 p.m., Steve Reinhardt wrote:
src/base/remote_gdb.cc, line 2
http://reviews.gem5.org/r/2540/diff/1/?file=42813#file42813line2
date?
Fixed.
On Dec. 4, 2014, 6:50 p.m., Steve Reinhardt wrote:
src/base/remote_gdb.cc, line 255
changeset bd68c6838b9f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=bd68c6838b9f
description:
sim: Ensure GDB interrupts the simulation at an instruction boundary.
Use the comInstEventQueue to ensure GDB interrupts the simulation at an
instruction
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2554/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2555/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2542/
---
(Updated Dec. 5, 2014, 10:45 a.m.)
Review request for Default.
Repository: gem5
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2542/
---
(Updated Dec. 5, 2014, 10:46 a.m.)
Review request for Default.
Repository: gem5
301 - 400 of 512 matches
Mail list logo
