Yeah, this looks like your system ran out of memory:
g++: fatal error: Killed signal terminated program lto1
That's probably the kernel going around killing processes using lots of
memory since it's running out.
Gabe
On Mon, May 24, 2021 at 7:27 PM Eliot Moss wrote:
> On 5/24/2021 10:12 PM, G
The last lines in your original email are:
[SOPARMHH] VirtIO9PBase -> X86/params/VirtIO9PBase.hh
[SOPARMHH] VirtIO9PDiod -> X86/params/VirtIO9PDiod.hh
[SOPARMHH] VirtIO9PProxy -> X86/params/VirtIO9PProxy.hh
[SOPARMHH] VirtIO9PSocket -> X86/params/VirtIO9PSocket.hh
[ CXX] X86/dev/virtio/fs
On 5/24/2021 10:04 PM, Gabe Black wrote:
Well, whatever the reason, there are no error messages in your original email
:-)
What you see is everything produced to the terminal by running the command.
What would you expect to see? :-)
Best - Eliot
On Mon, May 24, 2021 at 7:01 PM Eliot Moss m
Well, whatever the reason, there are no error messages in your original
email :-)
Gabe
On Mon, May 24, 2021 at 7:01 PM Eliot Moss wrote:
> On 5/24/2021 9:47 PM, Gabe Black wrote:
> > Hi Eliot, unfortunately this output doesn't seem to include stderr, and
> so doesn't have any of the
> > error
On 5/24/2021 4:43 PM, Gabe Black wrote:
> I don't think LTO strips debug symbols... But yes, LTO does significantly
> increase link time if your machine doesn't have lots of cores to parallelize
> the link. It slows it down in general, but with gcc you can parallelize the
> link with LTO where yo
Yeah, I wouldn't have expected that either, but if that's what you're
seeing it's hard to argue otherwise. I don't think that's an inherent
behavior of LTO, but it might be an unintended side effect somehow, maybe
pulled in indirectly? It's probably worth a Jira ticket.
Gabe
On Mon, May 24, 2021
Hi Eliot. The decoder, particularly the x86 decoder, is one of the most
complex areas of gem5, and unfortunately there isn't any comprehensive
documentation explaining how it works. I did put together this document a
while ago (
https://docs.google.com/document/d/1quwxZOPb181jVWAh_7nX7E6uJM-7d9VDU9
In regards to debug symbols on the stable branch: All i can say for sure is
the debug symbols are being stripped right now with LTO enabled by default,
and they aren't stripped if you pass `--no-lto`. I wouldn't have expected
LTO to work this way, but this is our observation and one of the reason's
I don't think LTO strips debug symbols... But yes, LTO does significantly
increase link time if your machine doesn't have lots of cores to
parallelize the link. It slows it down in general, but with gcc you can
parallelize the link with LTO where you can't without LTO for some reason,
and that outw
Thanks for the report Eliot. In this case there's no need to file a bug
report as we're about to produce a minor release of gem5 that will off LTO
by default. I'm not familiar with this particular problem you are facing,
but we've found we need to turn it off for other reasons (1. It increases
link
Dear Gem5-ers:
I have been trying to build Gem5 out of the box, for x86, on a VirtualBox
virtual machine set up for 64-bit Ubuntu 20.04 ("focal"). I can do
scons build/X86/gem5.opt
but it will succeed only if I disable link time optimization LTO using
--no-lto. I've tried various versions GCC
Hi, all --
I've been using an older version of Gem5 for some time (inherited from an
existing project) for some ARM simulations, but now am moving to do something
new on x86.
The particular task where I'd like some guidance is this:
I want to add an instruction that will send a command to the c
Thank you for your reply.
Any plans to support for aarch64？
发件人： Hoa Nguyenmailto:hoangu...@ucdavis.edu>>
收件人： Liyichaomailto:liyic...@huawei.com>>
抄送： gem5 users mailing listmailto:gem5-users@gem5.org>>
主题： Re: 答复: [gem5-users] Re: SPEC2017 in FS mode
时间： 20
Hi Victor,
I see the problem now.
In install-spec2017 script line 21
(https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/spec-2017/disk-image/spec-2017/install-spec2017.sh#21),
we replace the default gcc_dir so that specmake will use
Ubuntu-installed gcc rather than spec'
Hi Liyichao,
Currently, the spec-2017 image only works with X86.
Regards,
Hoa Nguyen
On 5/20/21, Liyichao wrote:
> Hi Hoa:
> Is the spec-2017 img just for X86?
>
> Does it support for AARCH64?Does it support for running with KVM+O3?
>
>
> -邮件原件-
> 发件人: Hoa Nguyen via gem5-use
15 matches
Mail list logo
