date:20141214

Re: [gem5-dev] Kernel panic caused by changeset 10552

2014-12-14 Thread Gabe Black via gem5-dev

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 Wed, Dec 10, 2014 at 1:40 AM, Gabe Black  wrote:
>
> 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 of undefined instruction exceptions in my own workload that weren't
> happening before, and I wonder if that's the cause.
>
> I'm not sure how that change helps support KVM in SE mode. Perhaps it
> should be reverted? Can you explain why it's necessary Alex? If it is,
> maybe we can reshape it a bit to avoid these side effects.
>
> Gabe
>
> On Wed, Dec 10, 2014 at 12:43 AM, 马久跃 via gem5-dev 
> wrote:
>
>> Hi everyone,
>>
>> I found "x86_64-vmlinux-2.6.28.4" panic when apply changeset 10552: cpuid,
>> x86: Enabling more features in CPUid. (2.6.22.9 works fine)
>> The gem5 also report "warn: x86 cpuid: unimplemented function 13", and
>> kernel report BUG at arch/x86/kernel/xsave.c:323 as following.
>>
>> Can anybody check/fix this bug?
>>
>> Thanks.
>>
>>  KERNEL OUTPUT
>> --
>> MPTABLE: APIC at: 0xFEE0
>> Processor #0 (Bootup-CPU)
>> I/O APIC #1 Version 17 at 0xFEC0.
>> Processors: 1
>> Allocating PCI resources starting at c400 (gap: c000:3fff)
>> Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
>> 127500
>> Kernel command line: earlyprintk=ttyS0 console=ttyS0 lpj=723
>> root=/dev/hda1
>> Initializing CPU#0
>> FP/SSE not shown under xsave features 0x80050033000d
>> [ cut here ]
>> kernel BUG at arch/x86/kernel/xsave.c:323!
>> invalid opcode:  [#1]
>> last sysfs file:
>> CPU 0
>> Modules linked in:
>> Pid: 0, comm: swapper Tainted: GW  2.6.28.4 #2
>> RIP: 0010:[]  []
>> xsave_cntxt_init+0x35/0x130
>> RSP: 0018:80769f48  EFLAGS: 00b8
>> RAX: 003c RBX:  RCX: 807cd460
>> RDX:  RSI: 0d5c RDI: 80702180
>> RBP:  R08:  R09: 03fd
>> R10:  R11:  R12: 
>> R13:  R14:  R15: 
>> FS:  () GS:807bf020()
>> knlGS:
>> CS:  0010 DS: 0018 ES: 0018 CR0: 80050033
>> CR2:  CR3: 00201000 CR4: 06a0
>> DR0:  DR1:  DR2: 
>> DR3:  DR6:  DR7: 
>> Process swapper (pid: 0, threadinfo 80768000, task
>> 806f5380)
>> Stack:
>>   8078f133 80795000 8078fe72
>>  8000896f59002087  8022ee104a50 80794000
>>  80795000 8076a98d  80795000
>> Call Trace:
>>  [] fpu_init+0x3e/0x8e []
>> cpu_init+0x222/0x240 [] start_kernel+0x16f/0x2d9
>> [] x86_64_start_kernel+0xd9/0xdfCode: 48 c1 e2 20 89 c0
>> 48
>> 8d 34 02 48 89 f0 48 89 35 12 a6 24 00 83 e0 03 48 83 f8 03 74 12 48 c7 c7
>> 50 74 67 80 31 c0 e8 9c 30 01 00 <0f> 0b eb fe f6 05 57 b7 1e 00 04 48 c7
>> 05
>> e5 a5 24 00 03 00 00
>> RIP  [] xsave_cntxt_init+0x35/0x130
>>  RSP 
>> ---[ end trace 4eaa2a86a8e2da22 ]---
>> Kernel panic - not syncing: Attempted to kill the idle task!
>>
>>
>> 
>> Jiuyue
>>
>>
>> ___
>> gem5-dev mailing list
>> gem5-dev@gem5.org
>> http://m5sim.org/mailman/listinfo/gem5-dev
>>
>
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2563: cpu: add support for outputing a protobuf formatted CPU trace

2014-12-14 Thread Gabe Black via gem5-dev


---
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 
protobufs.


src/cpu/SConscript


From context I know what this is trying to say, but the sentence doesn't 
really make sense.


- Gabe Black


On Dec. 10, 2014, 5:57 p.m., Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2563/
> ---
> 
> (Updated Dec. 10, 2014, 5:57 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10612:3e9fa4687536
> ---
> cpu: add support for outputing a protobuf formatted CPU trace
> 
> 
> Diffs
> -
> 
>   src/cpu/InstPBTrace.py PRE-CREATION 
>   src/cpu/SConscript 4e09ae443c96 
>   src/cpu/inst_pb_trace.hh PRE-CREATION 
>   src/cpu/inst_pb_trace.cc PRE-CREATION 
>   src/proto/SConscript 4e09ae443c96 
>   src/proto/inst.proto PRE-CREATION 
>   util/decode_inst_trace.py PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/2563/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali Saidi
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

2014-12-14 Thread Gabe Black via gem5-dev

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 expects. Can you please
provide more specific instructions how to reproduce the hang/crash you're
seeing? If this is working as expected, it would be good to get it checked
in and get KVM working again.

Gabe





$ M5_CPU2000=/usr/local/google/home/gabeblack/gem5/dist/m5/cpu2000/
./build/X86/gem5.opt configs/example/se.py -c
/usr/local/google/home/gabeblack/gem5/dist/m5/cpu2000/binaries/x86/linux/bzip2
--cpu-type=kvm -o 'input.source 1'
gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 compiled Dec 14 2014 21:18:54
gem5 started Dec 14 2014 21:49:12
gem5 executing on gabeblackz620.mtv.corp.google.com
command line: ./build/X86/gem5.opt configs/example/se.py -c
/usr/local/google/home/gabeblack/gem5/dist/m5/cpu2000/binaries/x86/linux/bzip2
--cpu-type=kvm -o input.source 1
Global frequency set at 1 ticks per second
warn: DRAM device capacity (8192 Mbytes) does not match the address range
assigned (512 Mbytes)
0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
 REAL SIMULATION 
info: KVM: Coalesced MMIO disabled by config.
info: Entering event queue @ 0.  Starting simulation...
warn: kvm-x86: MSR (0x12) unsupported by gem5. Skipping.
warn: kvm-x86: MSR (0x11) unsupported by gem5. Skipping.
warn: kvm-x86: MSR (0x4b564d01) unsupported by gem5. Skipping.
warn: kvm-x86: MSR (0x4b564d00) unsupported by gem5. Skipping.
warn: kvm-x86: MSR (0x4000) unsupported by gem5. Skipping.
warn: kvm-x86: MSR (0x4001) unsupported by gem5. Skipping.
warn: kvm-x86: MSR (0x4073) unsupported by gem5. Skipping.
warn: kvm-x86: MSR (0x4b564d02) unsupported by gem5. Skipping.
warn: kvm-x86: MSR (0x4b564d03) unsupported by gem5. Skipping.
warn: kvm-x86: MSR (0x4b564d04) unsupported by gem5. Skipping.
warn: kvm-x86: MSR (0x3a) unsupported by gem5. Skipping.
warn: kvm-x86: MSR (0x3b) unsupported by gem5. Skipping.
warn: kvm-x86: MSR (0x6e0) unsupported by gem5. Skipping.
warn: kvm-x86: MSR (0x1a0) unsupported by gem5. Skipping.
spec_init
Loading Input Data
Input data 1048576 bytes in length
Compressing Input Data, level 7
info: Increasing stack size by one page.
info: Increasing stack size by one page.
info: Increasing stack size by one page.
Compressed data 198546 bytes in length
Uncompressing Data
Uncompressed data 1048576 bytes in length
Uncompressed data compared correctly
Compressing Input Data, level 9
Compressed data 198677 bytes in length
Uncompressing Data
Uncompressed data 1048576 bytes in length
Uncompressed data compared correctly
Tested 1MB buffer: OK!
Exiting @ tick 13987682791500 because target called exit()
hack: Pretending totalOps is equivalent to totalInsts()

On Sat, Dec 13, 2014 at 12:12 AM, Andreas Hansson via gem5-dev <
gem5-dev@gem5.org> wrote:
>
> This patch should hopefully solve the issue with the refresh event:
> http://reviews.gem5.org/r/2573/
>
> Andreas
>
> On 11/12/2014 15:52, "Andreas Hansson via gem5-dev" 
> wrote:
>
> >Hi Alex, Mike,
> >
> >I¹ll try and fix this whole issue of the refresh event once and for all.
> >SimpleMemory should only really be used for fast-forwarding and high-level
> >sweeps, and I would like to ensure there are really no reasons to move
> >away from the DRAM controller.
> >
> >It seems the sensible thing to do is to use startup and drainResume as the
> >points where we check the mode of the memory system and either
> >disable/enable the refresh event of the DRAM controller.
> >
> >Hopefully I will have something working before the weekend.
> >
> >Andreas
> >
> >On 11/12/2014 15:32, "Dutu, Alexandru via gem5-dev" 
> >wrote:
> >
> >>Hi Mike,
> >>
> >>Are you running with SimpleMemory, SE or FS? On my AMD platform, for SE,
> >>I get very similar execution times with old implementation, for
> >>SimpleMemory and classic memory with detailed memory controller. Also
> >>what linux kernel are you using?
> >>
> >>Thanks,
> >>Alex
> >>
> >>-Original Message-
> >>From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of mike
> upton
> >>via gem5-dev
> >>Sent: Wednesday, December 10, 2014 3:59 PM
> >>To: gem5 Developer List
> >>Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
> >>
> >>I was testing this on both Intel and AMD platforms.
> >>
> >>The new code does seem to work for Intel platforms.
> >>
> >>The new code also seems to clean up a bunch of runtime warnings I was
> >>getting on AMD platforms.
> >>
> >>However the new code on AMD is either much slower, or it is stuck in a
> >>loop.
> >>A test that runs for 30 sec with the old code is running for more than 10
> >>mins, and still has a long way to go.
> >>
> >>
> >>
> >>On Wed, Dec 10, 2014 at 12:27 PM, Gabe Black via gem5-dev
> >> >>> wrote:
> >>
> >>> That's not actually extending the TSS limit, tha

Re: [gem5-dev] Update gem5-stable

2014-12-14 Thread Nilay Vaish via gem5-dev


I have updated gem5-stable to the version mentioned below.

--
Nilay

On Thu, 4 Dec 2014, Nilay Vaish wrote:


Hello everyone

Nearly four months have passed since we updated gem5-stable.  I am planning 
to move it forward on 15th December.  The changeset I have on my mind is:


changeset:   10436:bdb307e8be54
user:Andrew Lukefahr 
date:Sat Oct 11 15:02:22 2014 -0500
summary: sim: draining bug for fast-forwaring multiple cores


This would mean adding about 235 patches to gem5-stable.  Note that we no 
longer maintain the same changeset order between gem5 and gem5-stable. So I 
am willing to cherry pick bug fixes that were pushed after the changeset 
suggested.



--
Nilay



___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: Added tag stable_2014_12_14 for changeset bdb...

2014-12-14 Thread Nilay Vaish via gem5-dev

changeset a0cb57e1c072 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=a0cb57e1c072
description:
Added tag stable_2014_12_14 for changeset bdb307e8be54

diffstat:

 .hgtags |  1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diffs (8 lines):

diff -r 8fc6e7a835d1 -r a0cb57e1c072 .hgtags
--- a/.hgtags   Tue Dec 09 21:53:44 2014 -0800
+++ b/.hgtags   Sun Dec 14 16:21:04 2014 -0600
@@ -25,3 +25,4 @@
 6a043adb1e8d67fbb03ac5cee58dd26f75663714 stable_2013_10_14
 459491344fcf7f9e29250e71f33a7c7150f54d64 stable_2014_02_15
 cb2e6950956d475da97b04c41f19769ce2e8541a stable_2014_08_26
+bdb307e8be54a5808a9af2537e9261d88de6ed1b stable_2014_12_14
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Cron /z/m5/regression/do-regression --scratch all

2014-12-14 Thread Cron Daemon via gem5-dev

* 
build/SPARC/tests/opt/long/fs/80.solaris-boot/sparc/solaris/t1000-simple-atomic 
CHANGED!
* build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview-o3-dual 
CHANGED!
scons: *** Error 1
scons: *** Error 1
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* build/ALPHA/tests/opt/long/se/70.twolf/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA/tests/opt/long/se/30.eon/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3 passed.
* build/ALPHA/tests/opt/long/se/70.twolf/alpha/tru64/minor-timing passed.
* build/ALPHA/tests/opt/long/se/50.vortex/alpha/tru64/o3-timing passed.
* build/ALPHA/tests/opt/long/se/50.vortex/alpha/tru64/minor-timing passed.
* build/ALPHA/tests/opt/long/se/30.eon/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3-dual 
passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/long/se/60.bzip2/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/long/se/40.perlbmk/alpha/tru64/simple-timing passed.
* 
build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-switcheroo-full 
passed.
* build/ALPHA/tests/opt/long/se/30.eon/alpha/tru64/minor-timing passed.
* build/ALPHA/tests/opt/long/se/50.vortex/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA/tests/opt/long/se/50.vortex/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/long/se/60.bzip2/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed.
* build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-minor 
passed.
* 
build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 passed.
* build/ALPHA/tests/opt/long/se/20.parser/alpha/tru64/minor-timing passed.
* build/ALPHA/tests/opt/long/se/40.perlbmk/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/long/se/70.twolf/alpha/tru64/o3-timing passed.
* build/ALPHA/tests/opt/long/se/30.eon/alpha/tru64/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* build/ALPHA/tests/opt/long/se/70.twolf/alpha/tru64/simple-atomic passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.he

Re: [gem5-dev] Possible to fix bitunion now?

2014-12-14 Thread Andreas Hansson via gem5-dev

Hi Gabe,

I don¹t dare say whether this specific c++11 feature is supported or not,
but as Steve says, check what gcc 4.6 (and most importantly, the standard
library shipped with it) is able to do.

clang is usually a step ahead on this front, so I do not expect any issues.

Andreas

On 14/12/2014 12:37, "Steve Reinhardt via gem5-dev" 
wrote:

>Basically, yes.  Certainly any C++11 feature that's supported by our
>minimum revs of both g++ (4.6) and clang (??) is fair game.
>
>Steve
>
>On Sun, Dec 14, 2014 at 3:07 AM, Gabe Black via gem5-dev
>
>wrote:
>>
>> It sounds like from this:
>>
>> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=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 Black 
>>wrote:
>>
>> > 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 the future.
>> >
>> > The quick version of how BitUnions work is that they are a class
>>holding
>> > an anonymous union of bitfield classes. The only data inside the
>>bitfield
>> > class is an instance of the underlying type of the bitunion. When
>> accessing
>> > the bitfield, operator overloading makes it extract or set the
>>particular
>> > field in question. The way the underlying data is set or extracted is
>> > arbitrary and, unlike C bitfields, can be independent of endianness.
>> >
>> > So for instance, if you have a BitUnion64, it might expand to
>>something
>> > like this (pseudo-code-ey)
>> >
>> > class BitUnion64
>> > {
>> >   union {
>> > uint64_t data;
>> > class Bitfield<3, 1> a
>> > {
>> >   uint64_t data;
>> > }
>> > class Bitfield<5, 4> b
>> > {
>> >   uint64_t data;
>> > }
>> > };
>> >
>> > That works just fine, even if it is a little bit dodgy in the way it
>> > assumes the Bitfield classes are laid out. The problem is if you have
>>two
>> > bitfields of the same type (signed vs. unsigned, bit positions) and
>>you
>> > assign one to the other. What you expect to happen is that the value
>>will
>> > be extracted from one Bitfield, and then that value will be used to
>>fill
>> in
>> > the other. If the types aren't perfect matches for each other, that's
>> what
>> > happens. If they *are* perfect matches for each other though, they'll
>>be
>> > assigned directly from one to the other. Since each actually contains
>>a
>> > complete copy of the underlying data (shared with the other bitfields
>>and
>> > the parent class) the entire value will be overwritten with the entire
>> > other value, not just the bitfields.
>> >
>> > The thing you might use to solve this problem is to define a copy
>> > constructor/assignment operator for a Bitfield type that would force
>>it
>> to
>> > extract the bitfield from one and then insert it in the other like
>>you'd
>> > expect. The problem here is that you're not allowed to have
>>non-default
>> > constructors or something like that on types that go into unions
>>(maybe
>> > just anonymous unions?). I forget exactly what you were going to be
>> allowed
>> > to do that would let you fix this (constructor on an anonymous
>>union?),
>> but
>> > it sounded like it was coming down the pipe.
>> >
>> > Any idea what that feature was and if it's available now? I'd really
>>like
>> > to get this fixed. It's bugged me for years that it's been broken like
>> that.
>> >
>> > Gabe
>> >
>> ___
>> gem5-dev mailing list
>> gem5-dev@gem5.org
>> http://m5sim.org/mailman/listinfo/gem5-dev
>>
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev
>


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2548782

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Possible to fix bitunion now?

2014-12-14 Thread Steve Reinhardt via gem5-dev

Basically, yes.  Certainly any C++11 feature that's supported by our
minimum revs of both g++ (4.6) and clang (??) is fair game.

Steve

On Sun, Dec 14, 2014 at 3:07 AM, Gabe Black via gem5-dev 
wrote:
>
> It sounds like from this:
>
> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=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 Black  wrote:
>
> > 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 the future.
> >
> > The quick version of how BitUnions work is that they are a class holding
> > an anonymous union of bitfield classes. The only data inside the bitfield
> > class is an instance of the underlying type of the bitunion. When
> accessing
> > the bitfield, operator overloading makes it extract or set the particular
> > field in question. The way the underlying data is set or extracted is
> > arbitrary and, unlike C bitfields, can be independent of endianness.
> >
> > So for instance, if you have a BitUnion64, it might expand to something
> > like this (pseudo-code-ey)
> >
> > class BitUnion64
> > {
> >   union {
> > uint64_t data;
> > class Bitfield<3, 1> a
> > {
> >   uint64_t data;
> > }
> > class Bitfield<5, 4> b
> > {
> >   uint64_t data;
> > }
> > };
> >
> > That works just fine, even if it is a little bit dodgy in the way it
> > assumes the Bitfield classes are laid out. The problem is if you have two
> > bitfields of the same type (signed vs. unsigned, bit positions) and you
> > assign one to the other. What you expect to happen is that the value will
> > be extracted from one Bitfield, and then that value will be used to fill
> in
> > the other. If the types aren't perfect matches for each other, that's
> what
> > happens. If they *are* perfect matches for each other though, they'll be
> > assigned directly from one to the other. Since each actually contains a
> > complete copy of the underlying data (shared with the other bitfields and
> > the parent class) the entire value will be overwritten with the entire
> > other value, not just the bitfields.
> >
> > The thing you might use to solve this problem is to define a copy
> > constructor/assignment operator for a Bitfield type that would force it
> to
> > extract the bitfield from one and then insert it in the other like you'd
> > expect. The problem here is that you're not allowed to have non-default
> > constructors or something like that on types that go into unions (maybe
> > just anonymous unions?). I forget exactly what you were going to be
> allowed
> > to do that would let you fix this (constructor on an anonymous union?),
> but
> > it sounded like it was coming down the pipe.
> >
> > Any idea what that feature was and if it's available now? I'd really like
> > to get this fixed. It's bugged me for years that it's been broken like
> that.
> >
> > Gabe
> >
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Possible to fix bitunion now?

2014-12-14 Thread Gabe Black via gem5-dev

It sounds like from this:

http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=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 Black  wrote:

> 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 the future.
>
> The quick version of how BitUnions work is that they are a class holding
> an anonymous union of bitfield classes. The only data inside the bitfield
> class is an instance of the underlying type of the bitunion. When accessing
> the bitfield, operator overloading makes it extract or set the particular
> field in question. The way the underlying data is set or extracted is
> arbitrary and, unlike C bitfields, can be independent of endianness.
>
> So for instance, if you have a BitUnion64, it might expand to something
> like this (pseudo-code-ey)
>
> class BitUnion64
> {
>   union {
> uint64_t data;
> class Bitfield<3, 1> a
> {
>   uint64_t data;
> }
> class Bitfield<5, 4> b
> {
>   uint64_t data;
> }
> };
>
> That works just fine, even if it is a little bit dodgy in the way it
> assumes the Bitfield classes are laid out. The problem is if you have two
> bitfields of the same type (signed vs. unsigned, bit positions) and you
> assign one to the other. What you expect to happen is that the value will
> be extracted from one Bitfield, and then that value will be used to fill in
> the other. If the types aren't perfect matches for each other, that's what
> happens. If they *are* perfect matches for each other though, they'll be
> assigned directly from one to the other. Since each actually contains a
> complete copy of the underlying data (shared with the other bitfields and
> the parent class) the entire value will be overwritten with the entire
> other value, not just the bitfields.
>
> The thing you might use to solve this problem is to define a copy
> constructor/assignment operator for a Bitfield type that would force it to
> extract the bitfield from one and then insert it in the other like you'd
> expect. The problem here is that you're not allowed to have non-default
> constructors or something like that on types that go into unions (maybe
> just anonymous unions?). I forget exactly what you were going to be allowed
> to do that would let you fix this (constructor on an anonymous union?), but
> it sounded like it was coming down the pipe.
>
> Any idea what that feature was and if it's available now? I'd really like
> to get this fixed. It's bugged me for years that it's been broken like that.
>
> Gabe
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Kernel panic caused by changeset 10552

Re: [gem5-dev] Review Request 2563: cpu: add support for outputing a protobuf formatted CPU trace

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

Re: [gem5-dev] Update gem5-stable

[gem5-dev] changeset in gem5: Added tag stable_2014_12_14 for changeset bdb...

[gem5-dev] Cron /z/m5/regression/do-regression --scratch all

Re: [gem5-dev] Possible to fix bitunion now?

Re: [gem5-dev] Possible to fix bitunion now?

Re: [gem5-dev] Possible to fix bitunion now?

9 matches

Site Navigation

Mail list logo

Footer information