Re: [gem5-users] Link error building gem5.fast
I think for version 6.0-ish (potentially going away in the future?) you're supposed to add -flinker-output=rel as an option for the partial links. Unfortunately when I do that, I get a different internal error described here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866 Which was apparently fixed as recently as march of this year. Gabe On Mon, Jun 5, 2017 at 4:04 PM, Gabe Black wrote: > I think those are all doable options. I'll give this a whirl, but while > I'll try to have a quick turnaround I can't make guarantees since I'll be > going on vacation next week and need to get a few things done. I don't > think it'll be too bad to implement though, so it shouldn't be a problem. > > Gabe > > On Mon, Jun 5, 2017 at 3:23 PM, Jason Lowe-Power > wrote: > >> Hey Gabe, >> >> How hard would it be to have an option for partial linking? If we could >> have a --force-lto option that did the opposite (enable lto and disable >> partial linking), that would be great. But if this would be a giant scons >> pain, I understand :). >> >> Jason >> >> On Mon, Jun 5, 2017 at 5:21 PM Andreas Hansson >> wrote: >> >>> I think dropping LTO for the affected compilers is probably the right >>> option, but it is potentially quite a blow to performance if we simply >>> leave it at that. Back when I profiled LTO usage I remember seeing 10+ >>> percent difference with and without LTO. >>> >>> Andreas >>> >>> From: gem5-users on behalf of Jason >>> Lowe-Power >>> Reply-To: gem5 users mailing list >>> Date: Monday, 5 June 2017 at 23:16 >>> To: Gabe Black >>> Cc: gem5 users mailing list >>> >>> Subject: Re: [gem5-users] Link error building gem5.fast >>> >>> I'm fine with dropping LTO on gcc 4.9-6. (It also works on gcc 4.8 for >>> me, BTW.) I it's also failing for gcc 6 (see >>> https://travis-ci.org/powerjg/gem5-ci-test). >>> >>> If you make a patch for this, could you add some detailed comments so we >>> can "undo" this change when we all move to gcc 7+? >>> >>> Thanks for tracking this down! >>> >>> Jason >>> >>> On Mon, Jun 5, 2017 at 4:47 PM Gabe Black wrote: >>> I also used this thread/bug as a basis for my diagnosis. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548 On Mon, Jun 5, 2017 at 2:40 PM, Gabe Black wrote: > Ok, I did some digging around about this, and while a lot of the talk > between gcc devs sounds like gibberish to me, I did pick out bits and > pieces which makes me think this is just something that's broken in gcc of > particular versions. There's some documentation of the state of things in > gcc version 6 where it says things are fixed to the point where they can > be > worked with, and that in version 7 they expect them to be totally fixed > up: > > https://gcc.gnu.org/gcc-6/changes.html > > The problem seems to be that there were assumptions being made in the > LTO gcc plugin that the link was a final link all the time, and that weak > external symbols (the inline functions that might show up multiple times) > should be promoted to regular external symbols. That breaks things since, > in subsequent links, there are more copies of them and they all look like > they're supposed to be unique. > > What I think we should do is detect what situation we're in and react > accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8 seems > to work for me) we need to avoid doing either partial linking or LTO since > the combination doesn't work. It would be easier to make scons avoid LTO > since that would just be changing the compiler flags and not structurally > changing how the build flows or how the scons scripts are written. > > In versions 6.0 to 7.0, if those release notes are to be believed, we > would need to decide between doing the partial link with gcc or with ld. > It > sounds like ld is better since it would still do whole program > optimization, although again it might be more difficult to twist scon's > arm > and get it to do things that way since its linker command line uses gcc. > We > could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently > caused issues for people on macs. > > And then, in the glorious future where we're using gcc v7 which works > properly, or if you're using clang, we can stop worrying about it since -r > and -lto will play nicely together. > > Thoughts? > > Gabe > > On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power > wrote: > >> Hi Gabe, >> >> I think the follow "just works" by downloading the image from >> dockerhub. >> >> > docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash >> >> Or, to just download the image: >> >> > docker pull powerjg/gem5-gcc-6-build >> >> Let me know if that doesn't work for you. >> >> I searched around some to try to tr
Re: [gem5-users] Link error building gem5.fast
Hey Gabe, How hard would it be to have an option for partial linking? If we could have a --force-lto option that did the opposite (enable lto and disable partial linking), that would be great. But if this would be a giant scons pain, I understand :). Jason On Mon, Jun 5, 2017 at 5:21 PM Andreas Hansson wrote: > I think dropping LTO for the affected compilers is probably the right > option, but it is potentially quite a blow to performance if we simply > leave it at that. Back when I profiled LTO usage I remember seeing 10+ > percent difference with and without LTO. > > Andreas > > From: gem5-users on behalf of Jason > Lowe-Power > Reply-To: gem5 users mailing list > Date: Monday, 5 June 2017 at 23:16 > To: Gabe Black > Cc: gem5 users mailing list > > Subject: Re: [gem5-users] Link error building gem5.fast > > I'm fine with dropping LTO on gcc 4.9-6. (It also works on gcc 4.8 for me, > BTW.) I it's also failing for gcc 6 (see > https://travis-ci.org/powerjg/gem5-ci-test). > > If you make a patch for this, could you add some detailed comments so we > can "undo" this change when we all move to gcc 7+? > > Thanks for tracking this down! > > Jason > > On Mon, Jun 5, 2017 at 4:47 PM Gabe Black wrote: > >> I also used this thread/bug as a basis for my diagnosis. >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548 >> >> On Mon, Jun 5, 2017 at 2:40 PM, Gabe Black wrote: >> >>> Ok, I did some digging around about this, and while a lot of the talk >>> between gcc devs sounds like gibberish to me, I did pick out bits and >>> pieces which makes me think this is just something that's broken in gcc of >>> particular versions. There's some documentation of the state of things in >>> gcc version 6 where it says things are fixed to the point where they can be >>> worked with, and that in version 7 they expect them to be totally fixed up: >>> >>> https://gcc.gnu.org/gcc-6/changes.html >>> >>> The problem seems to be that there were assumptions being made in the >>> LTO gcc plugin that the link was a final link all the time, and that weak >>> external symbols (the inline functions that might show up multiple times) >>> should be promoted to regular external symbols. That breaks things since, >>> in subsequent links, there are more copies of them and they all look like >>> they're supposed to be unique. >>> >>> What I think we should do is detect what situation we're in and react >>> accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8 seems >>> to work for me) we need to avoid doing either partial linking or LTO since >>> the combination doesn't work. It would be easier to make scons avoid LTO >>> since that would just be changing the compiler flags and not structurally >>> changing how the build flows or how the scons scripts are written. >>> >>> In versions 6.0 to 7.0, if those release notes are to be believed, we >>> would need to decide between doing the partial link with gcc or with ld. It >>> sounds like ld is better since it would still do whole program >>> optimization, although again it might be more difficult to twist scon's arm >>> and get it to do things that way since its linker command line uses gcc. We >>> could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently >>> caused issues for people on macs. >>> >>> And then, in the glorious future where we're using gcc v7 which works >>> properly, or if you're using clang, we can stop worrying about it since -r >>> and -lto will play nicely together. >>> >>> Thoughts? >>> >>> Gabe >>> >>> On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power >>> wrote: >>> Hi Gabe, I think the follow "just works" by downloading the image from dockerhub. > docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash Or, to just download the image: > docker pull powerjg/gem5-gcc-6-build Let me know if that doesn't work for you. I searched around some to try to track down the issue. It seems that GCC doesn't love doing LTO and partial linking. There have been a number of bugs related to this in the past. But, all of the bugs that I found had been fixed before gcc 5. Cheers, Jason On Sun, Jun 4, 2017 at 4:37 PM Gabe Black wrote: > I was hoping we could leave the lto in the .cc->.o but take it out of > the partial links, and that that would fix the problem. If you have a > docker image I can try this all out on, that would be helpful. If I can > get > ahold of that somehow, I can try to figure out how to fix this on Monday. > I'd speculate what's happening is that little inline functions, etc., > which > I think are called "common" symbols are showing up more than once. > Normally > that's ok and the linker will figure that out and get rid of the extra > copies, but apparently here it isn't doing that. There's a scons variable > which you can use to disable lto in the fast build if
Re: [gem5-users] Link error building gem5.fast
I think dropping LTO for the affected compilers is probably the right option, but it is potentially quite a blow to performance if we simply leave it at that. Back when I profiled LTO usage I remember seeing 10+ percent difference with and without LTO. Andreas From: gem5-users mailto:gem5-users-boun...@gem5.org>> on behalf of Jason Lowe-Power mailto:ja...@lowepower.com>> Reply-To: gem5 users mailing list mailto:gem5-users@gem5.org>> Date: Monday, 5 June 2017 at 23:16 To: Gabe Black mailto:gabebl...@google.com>> Cc: gem5 users mailing list mailto:gem5-users@gem5.org>> Subject: Re: [gem5-users] Link error building gem5.fast I'm fine with dropping LTO on gcc 4.9-6. (It also works on gcc 4.8 for me, BTW.) I it's also failing for gcc 6 (see https://travis-ci.org/powerjg/gem5-ci-test). If you make a patch for this, could you add some detailed comments so we can "undo" this change when we all move to gcc 7+? Thanks for tracking this down! Jason On Mon, Jun 5, 2017 at 4:47 PM Gabe Black mailto:gabebl...@google.com>> wrote: I also used this thread/bug as a basis for my diagnosis. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548 On Mon, Jun 5, 2017 at 2:40 PM, Gabe Black mailto:gabebl...@google.com>> wrote: Ok, I did some digging around about this, and while a lot of the talk between gcc devs sounds like gibberish to me, I did pick out bits and pieces which makes me think this is just something that's broken in gcc of particular versions. There's some documentation of the state of things in gcc version 6 where it says things are fixed to the point where they can be worked with, and that in version 7 they expect them to be totally fixed up: https://gcc.gnu.org/gcc-6/changes.html The problem seems to be that there were assumptions being made in the LTO gcc plugin that the link was a final link all the time, and that weak external symbols (the inline functions that might show up multiple times) should be promoted to regular external symbols. That breaks things since, in subsequent links, there are more copies of them and they all look like they're supposed to be unique. What I think we should do is detect what situation we're in and react accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8 seems to work for me) we need to avoid doing either partial linking or LTO since the combination doesn't work. It would be easier to make scons avoid LTO since that would just be changing the compiler flags and not structurally changing how the build flows or how the scons scripts are written. In versions 6.0 to 7.0, if those release notes are to be believed, we would need to decide between doing the partial link with gcc or with ld. It sounds like ld is better since it would still do whole program optimization, although again it might be more difficult to twist scon's arm and get it to do things that way since its linker command line uses gcc. We could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently caused issues for people on macs. And then, in the glorious future where we're using gcc v7 which works properly, or if you're using clang, we can stop worrying about it since -r and -lto will play nicely together. Thoughts? Gabe On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power mailto:ja...@lowepower.com>> wrote: Hi Gabe, I think the follow "just works" by downloading the image from dockerhub. > docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash Or, to just download the image: > docker pull powerjg/gem5-gcc-6-build Let me know if that doesn't work for you. I searched around some to try to track down the issue. It seems that GCC doesn't love doing LTO and partial linking. There have been a number of bugs related to this in the past. But, all of the bugs that I found had been fixed before gcc 5. Cheers, Jason On Sun, Jun 4, 2017 at 4:37 PM Gabe Black mailto:gabebl...@google.com>> wrote: I was hoping we could leave the lto in the .cc->.o but take it out of the partial links, and that that would fix the problem. If you have a docker image I can try this all out on, that would be helpful. If I can get ahold of that somehow, I can try to figure out how to fix this on Monday. I'd speculate what's happening is that little inline functions, etc., which I think are called "common" symbols are showing up more than once. Normally that's ok and the linker will figure that out and get rid of the extra copies, but apparently here it isn't doing that. There's a scons variable which you can use to disable lto in the fast build if you want a workaround for right now, although using gem5.fast is a bit dangerous in the first place since I think it disables asserts, etc. Gabe On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power mailto:ja...@lowepower.com>> wrote: I tried passing -no-lto with ['-r', '-nostdlib'] on line SConstruct:688. However, that caused the error/warning: "/usr/bin/ld: build/X86/dev/io_device.fo
Re: [gem5-users] Link error building gem5.fast
I'm fine with dropping LTO on gcc 4.9-6. (It also works on gcc 4.8 for me, BTW.) I it's also failing for gcc 6 (see https://travis-ci.org/powerjg/gem5-ci-test). If you make a patch for this, could you add some detailed comments so we can "undo" this change when we all move to gcc 7+? Thanks for tracking this down! Jason On Mon, Jun 5, 2017 at 4:47 PM Gabe Black wrote: > I also used this thread/bug as a basis for my diagnosis. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548 > > On Mon, Jun 5, 2017 at 2:40 PM, Gabe Black wrote: > >> Ok, I did some digging around about this, and while a lot of the talk >> between gcc devs sounds like gibberish to me, I did pick out bits and >> pieces which makes me think this is just something that's broken in gcc of >> particular versions. There's some documentation of the state of things in >> gcc version 6 where it says things are fixed to the point where they can be >> worked with, and that in version 7 they expect them to be totally fixed up: >> >> https://gcc.gnu.org/gcc-6/changes.html >> >> The problem seems to be that there were assumptions being made in the LTO >> gcc plugin that the link was a final link all the time, and that weak >> external symbols (the inline functions that might show up multiple times) >> should be promoted to regular external symbols. That breaks things since, >> in subsequent links, there are more copies of them and they all look like >> they're supposed to be unique. >> >> What I think we should do is detect what situation we're in and react >> accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8 seems >> to work for me) we need to avoid doing either partial linking or LTO since >> the combination doesn't work. It would be easier to make scons avoid LTO >> since that would just be changing the compiler flags and not structurally >> changing how the build flows or how the scons scripts are written. >> >> In versions 6.0 to 7.0, if those release notes are to be believed, we >> would need to decide between doing the partial link with gcc or with ld. It >> sounds like ld is better since it would still do whole program >> optimization, although again it might be more difficult to twist scon's arm >> and get it to do things that way since its linker command line uses gcc. We >> could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently >> caused issues for people on macs. >> >> And then, in the glorious future where we're using gcc v7 which works >> properly, or if you're using clang, we can stop worrying about it since -r >> and -lto will play nicely together. >> >> Thoughts? >> >> Gabe >> >> On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power >> wrote: >> >>> Hi Gabe, >>> >>> I think the follow "just works" by downloading the image from dockerhub. >>> >>> > docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash >>> >>> Or, to just download the image: >>> >>> > docker pull powerjg/gem5-gcc-6-build >>> >>> Let me know if that doesn't work for you. >>> >>> I searched around some to try to track down the issue. It seems that GCC >>> doesn't love doing LTO and partial linking. There have been a number of >>> bugs related to this in the past. But, all of the bugs that I found had >>> been fixed before gcc 5. >>> >>> Cheers, >>> Jason >>> >>> On Sun, Jun 4, 2017 at 4:37 PM Gabe Black wrote: >>> I was hoping we could leave the lto in the .cc->.o but take it out of the partial links, and that that would fix the problem. If you have a docker image I can try this all out on, that would be helpful. If I can get ahold of that somehow, I can try to figure out how to fix this on Monday. I'd speculate what's happening is that little inline functions, etc., which I think are called "common" symbols are showing up more than once. Normally that's ok and the linker will figure that out and get rid of the extra copies, but apparently here it isn't doing that. There's a scons variable which you can use to disable lto in the fast build if you want a workaround for right now, although using gem5.fast is a bit dangerous in the first place since I think it disables asserts, etc. Gabe On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power wrote: > I tried passing -no-lto with ['-r', '-nostdlib'] on line > SConstruct:688. However, that caused the error/warning: > "/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to handle lto > object" for every lib.fo.partial. I guess the -lto option during .cc->.o > puts some data in the .o. Then, when partially linking with -r gcc gets > confused? > > Should I filter out the -lto=8 from all of the .cc->.o? I could have > mis-understood how to do this. > > Jason > > On Sun, Jun 4, 2017 at 4:08 PM Gabe Black > wrote: > >> Did you try filtering out the lto option from the partial link steps >> like I suggested? Look at how I do that
Re: [gem5-users] Link error building gem5.fast
Ok, I did some digging around about this, and while a lot of the talk between gcc devs sounds like gibberish to me, I did pick out bits and pieces which makes me think this is just something that's broken in gcc of particular versions. There's some documentation of the state of things in gcc version 6 where it says things are fixed to the point where they can be worked with, and that in version 7 they expect them to be totally fixed up: https://gcc.gnu.org/gcc-6/changes.html The problem seems to be that there were assumptions being made in the LTO gcc plugin that the link was a final link all the time, and that weak external symbols (the inline functions that might show up multiple times) should be promoted to regular external symbols. That breaks things since, in subsequent links, there are more copies of them and they all look like they're supposed to be unique. What I think we should do is detect what situation we're in and react accordingly. In gcc version 5.0-6.0 (maybe 4.9 or 4.8, although 4.8 seems to work for me) we need to avoid doing either partial linking or LTO since the combination doesn't work. It would be easier to make scons avoid LTO since that would just be changing the compiler flags and not structurally changing how the build flows or how the scons scripts are written. In versions 6.0 to 7.0, if those release notes are to be believed, we would need to decide between doing the partial link with gcc or with ld. It sounds like ld is better since it would still do whole program optimization, although again it might be more difficult to twist scon's arm and get it to do things that way since its linker command line uses gcc. We could pass -r to ld directly by wrapping it in -Wl,-r, but that apparently caused issues for people on macs. And then, in the glorious future where we're using gcc v7 which works properly, or if you're using clang, we can stop worrying about it since -r and -lto will play nicely together. Thoughts? Gabe On Sun, Jun 4, 2017 at 3:11 PM, Jason Lowe-Power wrote: > Hi Gabe, > > I think the follow "just works" by downloading the image from dockerhub. > > > docker run -v `pwd`:`pwd` -it powerjg/gem5-gcc-6-build /bin/bash > > Or, to just download the image: > > > docker pull powerjg/gem5-gcc-6-build > > Let me know if that doesn't work for you. > > I searched around some to try to track down the issue. It seems that GCC > doesn't love doing LTO and partial linking. There have been a number of > bugs related to this in the past. But, all of the bugs that I found had > been fixed before gcc 5. > > Cheers, > Jason > > On Sun, Jun 4, 2017 at 4:37 PM Gabe Black wrote: > >> I was hoping we could leave the lto in the .cc->.o but take it out of the >> partial links, and that that would fix the problem. If you have a docker >> image I can try this all out on, that would be helpful. If I can get ahold >> of that somehow, I can try to figure out how to fix this on Monday. I'd >> speculate what's happening is that little inline functions, etc., which I >> think are called "common" symbols are showing up more than once. Normally >> that's ok and the linker will figure that out and get rid of the extra >> copies, but apparently here it isn't doing that. There's a scons variable >> which you can use to disable lto in the fast build if you want a workaround >> for right now, although using gem5.fast is a bit dangerous in the first >> place since I think it disables asserts, etc. >> >> Gabe >> >> On Sun, Jun 4, 2017 at 2:11 PM, Jason Lowe-Power >> wrote: >> >>> I tried passing -no-lto with ['-r', '-nostdlib'] on line >>> SConstruct:688. However, that caused the error/warning: >>> "/usr/bin/ld: build/X86/dev/io_device.fo: plugin needed to handle lto >>> object" for every lib.fo.partial. I guess the -lto option during .cc->.o >>> puts some data in the .o. Then, when partially linking with -r gcc gets >>> confused? >>> >>> Should I filter out the -lto=8 from all of the .cc->.o? I could have >>> mis-understood how to do this. >>> >>> Jason >>> >>> On Sun, Jun 4, 2017 at 4:08 PM Gabe Black wrote: >>> Did you try filtering out the lto option from the partial link steps like I suggested? Look at how I do that for -shared as an example. Gabe On May 24, 2017 2:00 PM, "Jason Lowe-Power" wrote: > Hi everyone, > > So I've been able to reproduce the problem. I would bet it's due to > the new partial linking code (https://gem5.googlesource. > com/public/gem5/+/6bdd897f04f4efdf90d0761c6d31d3f960f4eacf). I'm not > sure what the solution is, yet, or if I'll have time to look at it in the > next few day. Gabe might have an idea, though, if that is the problem. > > Here's a matrix of what compilers are working and which aren't > (gcc-4.8 is working, too, though not tested on travis). > https://travis-ci.org/powerjg/gem5-ci-test/builds/235779432 > > Jason > > On Tue, May 23, 2017 at 4:33 PM Moussa,
[gem5-users] Kernel panic - not syncing: No working init found.
I am trying to run a simple hello world program in FS mode (ARM ISA)
following these steps:
$ wget http://www.m5sim.org/dist/current/arm/aarch-system-2014-10.tar.xz
$ tar xf aarch-system-2014-10.tar.xz
$ mkdir tmpdir
$ sudo mount -o loop,offset=32256 disks/aarch64-ubuntu-trusty-headless.img
tmpdir
$ cd tmpdir
$ cd etc/init
$ sudo cp /home/iiitd/Desktop/tty-gem5.conf .
$ cd..
$ cd sbin
$ sudo cp /home/iiitd/gem5/util/m5/m5 .
$ cd ..
$ sudo mkdir benchmark
$ sudo cp /home/iiitd/Desktop/mine/hello6 benchmark
$ cd..
$ sudo umount tmpdir
$ echo "export M5_PATH=/home/iiitd/full-system-2014" >> ~/.bashrc
$ source ~/.bashrc
$ cd gem5
$ build/ARM/gem5.opt configs/example/fs.py
--disk-image=/home/iiitd/full-system-2014/disks/aarch64-ubuntu-trusty-headless.img
--script=./home/iiitd/a.rcS
In another terminal:
$ cd gem5/util/term
$ ./m5term localhost 3457
m5 slave terminal: Terminal 0
Freeing unused kernel memory: 292K (806aa000 - 806f3000)
request_module: runaway loop modprobe binfmt-464c
Starting init: /sbin/init exists but couldn't execute it (error -8)
Starting init: /etc/init exists but couldn't execute it (error -13)
request_module: runaway loop modprobe binfmt-464c
Starting init: /bin/sh exists but couldn't execute it (error -8)
Kernel panic - not syncing: No working init found. Try passing init=
option to kernel. See Linux Documentation/init.txt for guidance.
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc2 #1
[<80016954>] (unwind_backtrace+0x0/0xf4) from [<80012424>]
(show_stack+0x10/0x14)
[<80012424>] (show_stack+0x10/0x14) from [<804f9bd4>] (dump_stack+0x98/0xc4)
[<804f9bd4>] (dump_stack+0x98/0xc4) from [<804f6db4>] (panic+0xa0/0x1e4)
[<804f6db4>] (panic+0xa0/0x1e4) from [<804f4408>] (cpu_die+0x0/0x70)
[<804f4408>] (cpu_die+0x0/0x70) from [<>] ( (null))
I tried to use the recent images from "
http://www.m5sim.org/dist/current/arm/aarch-system-20170426.tar.xz and
followed the above steps.
:~/gem5$ build/ARM/gem5.opt configs/example/fs.py
--disk-image=/home/iiitd/full-system-2014/disks/aarch64-ubuntu-trusty-headless.img
--script=./home/iiitd/a.rcS
gem5 Simulator System. http://gem5.org
---
-
Traceback (most recent call last):
File "", line 1, in
File "/home/iiitd/gem5/src/python/m5/main.py", line 400, in main
exec filecode in scope
File "configs/example/fs.py", line 341, in
test_sys = build_test_system(np)
File "configs/example/fs.py", line 103, in build_test_system
ruby=options.ruby)
File "/home/iiitd/gem5/configs/common/FSConfig.py", line 304, in
makeArmSystem
self.kernel = binary(default_kernels[machine_type])
File "/home/iiitd/gem5/configs/common/SysPaths.py", line 49, in binary
return searchpath(binary.path, filename)
File "/home/iiitd/gem5/configs/common/SysPaths.py", line 41, in searchpath
raise IOError, "Can't find file '%s' on path." % filename
IOError: Can't find file 'vmlinux.aarch32.ll_20131205.0-gem5' on path.
In the newly downloaded binaries, there is no file called
"vmlinux.aarch32.ll_20131205.0-gem5". So, I think I have to change the dtb
and kernel names in FSConfig.py into appropriate one. But, I am not sure
which dtb and kernel shall we use. I tried with the following with no
success:
In FSConfig.py:
default_dtbs = {
"RealViewEB": None,
"RealViewPBX": None,
"VExpress_EMM": "armv7_gem5_v1_16cpu.20170426.dtb",
"VExpress_EMM64":
"vexpress-v2p-ca15-tc1-gem5_4cpus.20170426.dtb",
}
default_kernels = {
"RealViewEB": "vmlinux.arm.smp.fb.2.6.38.8",
"RealViewPBX": "vmlinux.arm.smp.fb.2.6.38.8",
"VExpress_EMM": "vmlinux.vexpress_gem5_v1.20170426",
"VExpress_EMM64": "vmlinux.vexpress_gem5_v1_64.20170426",
}
Thank you.
--
Mitali Sinha,
PhD Scholar,
IIIT Delhi
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] 8 or more CPUs in a aarch64 configuration
Hey everyone, I'm running the latest gem5 version using a the gem5 ARM 4.3 Linux kernel in a aarch64 configuration with the default ubuntu-trusty-headless.img. I attached a second SCSI disk image with several microbenchmarks. The simulation mode is atomic without any caches. The bootloader is up-to-date. When I boot the configuration with 4 cores the benchmarks execute as expected. However when I switch to 8 (or more cores by enabling gem5_extensions) I occasionally get this error: gem5.opt: build/ARM/sim/eventq_impl.hh:44: void EventQueue::schedule(Event*, Tick, bool): Assertion `when >= getCurTick()' failed. Program aborted at tick 18446696982122995000 --- BEGIN LIBC BACKTRACE --- gem5.opt(_Z15print_backtracev+0x15)[0xe8b3b5] gem5.opt(_Z12abortHandleri+0x39)[0xea7c19] /usr/lib64/libpthread.so.0(+0xf370)[0x2ae213d4d370] /usr/lib64/libc.so.6(gsignal+0x37)[0x2ae2155c61d7] /usr/lib64/libc.so.6(abort+0x148)[0x2ae2155c78c8] /usr/lib64/libc.so.6(+0x2e146)[0x2ae2155bf146] /usr/lib64/libc.so.6(+0x2e1f2)[0x2ae2155bf1f2] gem5.opt(_ZN9ArchTimer13updateCounterEv+0x207)[0xde2fa7] gem5.opt(_ZN6ArmISA3ISA10setMiscRegEiRKmP13ThreadContext+0x1475)[0x9b7c15] gem5.opt(_ZNK10ArmISAInst5Msr647executeEP11ExecContextPN5Tra ce10InstRecordE+0x375)[0x1a59c25] gem5.opt(_ZN15AtomicSimpleCPU4tickEv+0x26d)[0xbed29d] gem5.opt(_ZN10EventQueue10serviceOneEv+0xb1)[0xe98831] gem5.opt(_Z9doSimLoopP10EventQueue+0x38)[0xec3828] gem5.opt(_Z8simulatem+0x1fb)[0xec3dbb] gem5.opt[0xc944dd] gem5.opt(PyEval_EvalFrameEx+0x534d)[0x1dcf3dd] gem5.opt(PyEval_EvalCodeEx+0x89c)[0x1dd0f7c] gem5.opt(PyEval_EvalFrameEx+0x5130)[0x1dcf1c0] gem5.opt(PyEval_EvalCodeEx+0x89c)[0x1dd0f7c] gem5.opt(PyEval_EvalFrameEx+0x5130)[0x1dcf1c0] gem5.opt(PyEval_EvalCodeEx+0x89c)[0x1dd0f7c] gem5.opt(PyEval_EvalFrameEx+0x54a5)[0x1dcf535] gem5.opt(PyEval_EvalCodeEx+0x89c)[0x1dd0f7c] gem5.opt(PyEval_EvalFrameEx+0x5130)[0x1dcf1c0] gem5.opt(PyEval_EvalCodeEx+0x89c)[0x1dd0f7c] gem5.opt(PyEval_EvalCode+0x19)[0x1dd1069] gem5.opt(PyRun_StringFlags+0xf5)[0x1df8ac5] gem5.opt(_Z6m5MainiPPc+0x7f)[0xea748f] gem5.opt(main+0x33)[0x8dae93] /usr/lib64/libc.so.6(__libc_start_main+0xf5)[0x2ae2155b2b35] gem5.opt[0x93575f] Has anyone else experienced this recently? Is this a known problem? I found this thread from several months ago, but it remained unanswered. https://www.mail-archive.com/gem5-users@gem5.org/msg13982.html It seems to be a very similar if not exact the same problem. I would really appreciate if someone could help me out on this for my thesis work! -Tim ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
