[gem5-users] Re: Building Gem5 on Ubuntu 20.04 - Failure details

[Gabe Black via gem5-users]

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, Gabe Black wrote:
> > 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/fs9p.cc -> .o
> >   [SOPARMCC] AMPMPrefetcher -> X86/params/AMPMPrefetcher.cc
> >   [ CXX] X86/params/AMPMPrefetcher.cc -> .o
> >   [SOPARMCC] AccessMapPatternMatching ->
> X86/params/AccessMapPatternMatching.cc
> >   [ CXX] X86/params/AccessMapPatternMatching.cc -> .o
> >   [SOPARMCC] AtomicSimpleCPU -> X86/params/AtomicSimpleCPU.cc
> >   [ CXX] X86/params/AtomicSimpleCPU.cc -> .o
> >   [SOPARMCC] BIPRP -> X86/params/BIPRP.cc
> >   [ CXX] X86/params/BIPRP.cc -> .o
> >
> > Did it get cut off?
>
> Yes; maybe the mailing list has a max length?  Here's what was at the end:
>
>   [   SHCXX] drampower/src/MemArchitectureSpec.cc -> .os
>   [   SHCXX] drampower/src/MemCommand.cc -> .os
>   [   SHCXX] drampower/src/MemPowerSpec.cc -> .os
>   [   SHCXX] drampower/src/MemTimingSpec.cc -> .os
>   [   SHCXX] drampower/src/MemoryPowerModel.cc -> .os
>   [   SHCXX] drampower/src/MemorySpecification.cc -> .os
>   [   SHCXX] drampower/src/Parameter.cc -> .os
>   [   SHCXX] drampower/src/Parametrisable.cc -> .os
>   [   SHCXX] drampower/src/libdrampower/LibDRAMPower.cc -> .os
>   [   SHCXX] drampower/src/CAHelpers.cc -> .os
>   [   SHCXX] drampower/src/CmdHandlers.cc -> .os
>   [   SHCXX] drampower/src/MemBankWiseParams.cc -> .os
>   [  AR]  -> drampower/libdrampower.a
>   [  RANLIB]  -> drampower/libdrampower.a
>   [LINK]  -> X86/gem5.opt
> g++: fatal error: Killed signal terminated program lto1
> compilation terminated.
> make: *** [/tmp/ccEY6Dte.mk:41: /tmp/gem5.opt.Gp3kKc.ltrans13.ltrans.o]
> Error 1
> make: *** Waiting for unfinished jobs
> lto-wrapper: fatal error: make returned 2 exit status
> compilation terminated.
> /usr/bin/ld: error: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> scons: *** [build/X86/gem5.opt] Error 1
> scons: building terminated because of errors.
>
> Hope this comes through for you.  I thought the whole thing went
> to the list ... EM
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Building Gem5 on Ubuntu 20.04 - Failure details

[Gabe Black via gem5-users]

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/fs9p.cc -> .o
 [SOPARMCC] AMPMPrefetcher -> X86/params/AMPMPrefetcher.cc
 [ CXX] X86/params/AMPMPrefetcher.cc -> .o
 [SOPARMCC] AccessMapPatternMatching -> X86/params/AccessMapPatternMat
ching.cc
 [ CXX] X86/params/AccessMapPatternMatching.cc -> .o
 [SOPARMCC] AtomicSimpleCPU -> X86/params/AtomicSimpleCPU.cc
 [ CXX] X86/params/AtomicSimpleCPU.cc -> .o
 [SOPARMCC] BIPRP -> X86/params/BIPRP.cc
 [ CXX] X86/params/BIPRP.cc -> .o

Did it get cut off?

On Mon, May 24, 2021 at 7:06 PM Eliot Moss  wrote:

> 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...@cs.umass.edu>> 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 messages.
> >
> > The |& below puts stdout and stderr together.  So it has all the
> error
> > messages that were produced by this combination of flags.  If I
> additionally
> > set -flto-record, in the past I have gotten a number of megabytes of
> messages
> > complaining about things missing in debug-related sections of
> decoder.o (I
> > forget which decoder.o - sorry).  I can try to generate that as
> well, if you
> > think it will help ...
> >
> > EM
> >
> > (large output trimmed)
> >
> >   > On Mon, May 24, 2021 at 6:44 PM Eliot Moss via gem5-users <
> gem5-users@gem5.org
> > 
> >   > >>
> wrote:
> >   >
> >   > This is more for the record.  I set up a docker according to
> the Gem5 web
> >   > pages, using the Ubuntu 20.04.  I made sure my git clone of
> current gem5 was
> >   > not modified and I removed the build/ hierarchy.  In /gem5 I
> ran this command:
> >   >
> >   > scons build/X86/gem5.opt -j2 |& tee gem5.opt.out.txt
> >
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Building Gem5 on Ubuntu 20.04 - Failure details

[Eliot Moss via gem5-users]

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 mailto:m...@cs.umass.edu>> 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 messages.

The |& below puts stdout and stderr together.  So it has all the error
messages that were produced by this combination of flags.  If I additionally
set -flto-record, in the past I have gotten a number of megabytes of 
messages
complaining about things missing in debug-related sections of decoder.o (I
forget which decoder.o - sorry).  I can try to generate that as well, if you
think it will help ...

EM

(large output trimmed)

  > On Mon, May 24, 2021 at 6:44 PM Eliot Moss via gem5-users 
mailto:gem5-users@gem5.org>
  > >> wrote:
  >
  >     This is more for the record.  I set up a docker according to the 
Gem5 web
  >     pages, using the Ubuntu 20.04.  I made sure my git clone of current 
gem5 was
  >     not modified and I removed the build/ hierarchy.  In /gem5 I ran 
this command:
  >
  >     scons build/X86/gem5.opt -j2 |& tee gem5.opt.out.txt


___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Building Gem5 on Ubuntu 20.04 - Failure details

[Gabe Black via gem5-users]

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 messages.
>
> The |& below puts stdout and stderr together.  So it has all the error
> messages that were produced by this combination of flags.  If I
> additionally
> set -flto-record, in the past I have gotten a number of megabytes of
> messages
> complaining about things missing in debug-related sections of decoder.o (I
> forget which decoder.o - sorry).  I can try to generate that as well, if
> you
> think it will help ...
>
> EM
>
> (large output trimmed)
>
>  > On Mon, May 24, 2021 at 6:44 PM Eliot Moss via gem5-users <
> gem5-users@gem5.org
>  > > wrote:
>  >
>  > This is more for the record.  I set up a docker according to the
> Gem5 web
>  > pages, using the Ubuntu 20.04.  I made sure my git clone of current
> gem5 was
>  > not modified and I removed the build/ hierarchy.  In /gem5 I ran
> this command:
>  >
>  > scons build/X86/gem5.opt -j2 |& tee gem5.opt.out.txt
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Building Gem5 on Ubuntu 20.04

[Eliot Moss via gem5-users]

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 you can't without LTO for some reason, and that
> outweighs the other overhead if you have enough cores to throw at it.

Earlier editions of Gem5 build gem5.fast.unstripped using LTO.

> Especially when running in a virtual machine, you might just be running out
> of memory. LTO will use more ram, and if you run out things will fail in
> potentially strange ways.

While I give the machine a fair amount of RAM, I will try giving it more.

> It sounds like you have a workaround for now so this may be a moot point,
> but in general, when you report compiler errors (or errors in general) it's
> very helpful to provide the error output instead of just describing the
> errors. That provides a lot of helpful detail which can make diagnosing the
> problem much easier.

Well, the workaround is not to optimize, though I have also seen builds fail
that way too.  (I am going all the way back to deleting the the whole build/
hierarchy and seeing if that avoids the problems.)

Thanks for your help.  If it continues to break, I will post the entire log of
the build.

Regards - Eliot
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Building Gem5 on Ubuntu 20.04

[Gabe Black via gem5-users]

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 at 1:48 PM Bobby Bruce  wrote:

> 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 we're going to disable it by default.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Mon, May 24, 2021 at 1: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 you can't without LTO for some reason,
>> and that outweighs the other overhead if you have enough cores to throw at
>> it.
>>
>> Especially when running in a virtual machine, you might just be running
>> out of memory. LTO will use more ram, and if you run out things will fail
>> in potentially strange ways.
>>
>> It sounds like you have a workaround for now so this may be a moot point,
>> but in general, when you report compiler errors (or errors in general) it's
>> very helpful to provide the error output instead of just describing the
>> errors. That provides a lot of helpful detail which can make diagnosing the
>> problem much easier.
>>
>> Gabe
>>
>> On Mon, May 24, 2021 at 1:07 PM Bobby Bruce via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> 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
>>> links times for some users to unacceptable levels and 2. LTO strips debug
>>> symbols which you'll need if you want to run tools such as GDB).
>>>
>>> I'm hoping we can ship the minor release sometime this week!
>>>
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 3050,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>>>
>>> On Mon, May 24, 2021 at 12:43 PM Eliot Moss via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
 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 - 7, 8, 9, and 10 - and all
 produce the same result.  (I think the key thing is probably something
 in
 binutils, but I don't know what version to try to obtain, and this
 version of
 Ubuntu does not readily offer anything other than 2.34.)

 Searching the web about this general problem mostly produces the
 "solution" of
 disabling LTO.  So, where should we / I file a bug report?  By turning
 on LTO
 reporting, I have found that the proximal cause is that decoder.o does
 not
 have a .debug_str section and yet there are a huge number of references
 to
 things that should be there (labels, I guess - the decode *would* have
 a lot
 of those!).

 Regards - Eliot
 ___
 gem5-users mailing list -- gem5-users@gem5.org
 To unsubscribe send an email to gem5-users-le...@gem5.org
 %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

>>> ___
>>> gem5-users mailing list -- gem5-users@gem5.org
>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Guidance on adding an x86 instruction

[Gabe Black via gem5-users]

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-7d9VDU9KxKkGmIrY/edit#heading=h.ogwesp50kyg)
which describes how the decoders in gem5 work in general, although I
haven't looked at it in a while and I don't remember exactly what's in
there.

As far as the tags which describe where an instructions operands come from,
the most important part of the implementation is specialize.py, I think. It
may have a slightly different name. That file implements the code which
parses the tags and prepares operands for the instruction, whether they're
registers, address components, etc. The tags themselves are based on the
operand description shorthand used in the AMD manuals in their instruction
reference, where generally one letter describes where the operand comes
from, and another letter describes the operand size. The actual size will
usually depend on other factors like the default operand size, the mode
you're in, etc, so the letter for the size really describes a pattern of
sizing than a particular size.

The microops themselves are more like what you would see in other ISAs
since they're the actual instructions which get executed by the CPUs. The
one additional difference is that they plug into the microcode assembler so
that they can be used in macroops. That's done with a python class which is
instantiated using the operands from the microcode, so, roughtly speaking:

add r1, r2, r3, operand_size=2

could map to:

Add(r1, r2, r3, operand_size=2)

where Add is the python class which represents the microop. The variables
r1, r2,  and r3 would be defined elsewhere as strings which will eventually
get pasted into the C++ and would be the index for r1, r2, r3, etc.

Gabe

On Mon, May 24, 2021 at 11:52 AM Eliot Moss via gem5-users <
gem5-users@gem5.org> wrote:

> 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 cache(s).  It
> does not need to mention a specific address, but may send some data.  I was
> thinking of encoding it the same way as clwb, but using the currently
> disallowed 11 (i.e., 3) combination of the mod/rm bits.  This generally
> indicates a register as opposed to a memory operand.  I think I have found
> more or less where to do this in the decoder, but if someone would respond
> about that, it would be helpful.
>
> Then there is the question of the other steps of adding an instruction,
> which
> starts getting more mysterious (e.g., what does Iz, for example mean, and
> is
> it what I want if I want this new instruction to have a register operand?).
>
> It will seem I'll need to add a micro-op as well.  I can follow the clwb
> model
> for that, except that this special thing will probably use some new flag in
> its request/packet that will head toward the cache (and of course I will be
> extending the cache to notice and handle that for the new thing I'm
> devising).
>
> An overall sketch of how to accomplish this successfully and going with the
> flow of the design would be great.  If there are specific pieces of
> documentation I should be looking at it, pointers to them would also be
> gratefully accepted.
>
> Regards, and thanks in advance - Eliot Moss
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Building Gem5 on Ubuntu 20.04

[Bobby Bruce via gem5-users]

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
we're going to disable it by default.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, May 24, 2021 at 1: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 you can't without LTO for some reason,
> and that outweighs the other overhead if you have enough cores to throw at
> it.
>
> Especially when running in a virtual machine, you might just be running
> out of memory. LTO will use more ram, and if you run out things will fail
> in potentially strange ways.
>
> It sounds like you have a workaround for now so this may be a moot point,
> but in general, when you report compiler errors (or errors in general) it's
> very helpful to provide the error output instead of just describing the
> errors. That provides a lot of helpful detail which can make diagnosing the
> problem much easier.
>
> Gabe
>
> On Mon, May 24, 2021 at 1:07 PM Bobby Bruce via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> 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
>> links times for some users to unacceptable levels and 2. LTO strips debug
>> symbols which you'll need if you want to run tools such as GDB).
>>
>> I'm hoping we can ship the minor release sometime this week!
>>
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Mon, May 24, 2021 at 12:43 PM Eliot Moss via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> 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 - 7, 8, 9, and 10 - and all
>>> produce the same result.  (I think the key thing is probably something in
>>> binutils, but I don't know what version to try to obtain, and this
>>> version of
>>> Ubuntu does not readily offer anything other than 2.34.)
>>>
>>> Searching the web about this general problem mostly produces the
>>> "solution" of
>>> disabling LTO.  So, where should we / I file a bug report?  By turning
>>> on LTO
>>> reporting, I have found that the proximal cause is that decoder.o does
>>> not
>>> have a .debug_str section and yet there are a huge number of references
>>> to
>>> things that should be there (labels, I guess - the decode *would* have a
>>> lot
>>> of those!).
>>>
>>> Regards - Eliot
>>> ___
>>> gem5-users mailing list -- gem5-users@gem5.org
>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Building Gem5 on Ubuntu 20.04

[Gabe Black via gem5-users]

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 outweighs the other overhead if you have enough cores to throw at
it.

Especially when running in a virtual machine, you might just be running out
of memory. LTO will use more ram, and if you run out things will fail in
potentially strange ways.

It sounds like you have a workaround for now so this may be a moot point,
but in general, when you report compiler errors (or errors in general) it's
very helpful to provide the error output instead of just describing the
errors. That provides a lot of helpful detail which can make diagnosing the
problem much easier.

Gabe

On Mon, May 24, 2021 at 1:07 PM Bobby Bruce via gem5-users <
gem5-users@gem5.org> wrote:

> 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
> links times for some users to unacceptable levels and 2. LTO strips debug
> symbols which you'll need if you want to run tools such as GDB).
>
> I'm hoping we can ship the minor release sometime this week!
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Mon, May 24, 2021 at 12:43 PM Eliot Moss via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> 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 - 7, 8, 9, and 10 - and all
>> produce the same result.  (I think the key thing is probably something in
>> binutils, but I don't know what version to try to obtain, and this
>> version of
>> Ubuntu does not readily offer anything other than 2.34.)
>>
>> Searching the web about this general problem mostly produces the
>> "solution" of
>> disabling LTO.  So, where should we / I file a bug report?  By turning on
>> LTO
>> reporting, I have found that the proximal cause is that decoder.o does not
>> have a .debug_str section and yet there are a huge number of references to
>> things that should be there (labels, I guess - the decode *would* have a
>> lot
>> of those!).
>>
>> Regards - Eliot
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Building Gem5 on Ubuntu 20.04

[Bobby Bruce via gem5-users]

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
links times for some users to unacceptable levels and 2. LTO strips debug
symbols which you'll need if you want to run tools such as GDB).

I'm hoping we can ship the minor release sometime this week!

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, May 24, 2021 at 12:43 PM Eliot Moss via gem5-users <
gem5-users@gem5.org> wrote:

> 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 - 7, 8, 9, and 10 - and all
> produce the same result.  (I think the key thing is probably something in
> binutils, but I don't know what version to try to obtain, and this version
> of
> Ubuntu does not readily offer anything other than 2.34.)
>
> Searching the web about this general problem mostly produces the
> "solution" of
> disabling LTO.  So, where should we / I file a bug report?  By turning on
> LTO
> reporting, I have found that the proximal cause is that decoder.o does not
> have a .debug_str section and yet there are a huge number of references to
> things that should be there (labels, I guess - the decode *would* have a
> lot
> of those!).
>
> Regards - Eliot
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Building Gem5 on Ubuntu 20.04

[Eliot Moss via gem5-users]

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 - 7, 8, 9, and 10 - and all
produce the same result.  (I think the key thing is probably something in
binutils, but I don't know what version to try to obtain, and this version of
Ubuntu does not readily offer anything other than 2.34.)

Searching the web about this general problem mostly produces the "solution" of
disabling LTO.  So, where should we / I file a bug report?  By turning on LTO
reporting, I have found that the proximal cause is that decoder.o does not
have a .debug_str section and yet there are a huge number of references to
things that should be there (labels, I guess - the decode *would* have a lot
of those!).

Regards - Eliot
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Guidance on adding an x86 instruction

[Eliot Moss via gem5-users]

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 cache(s).  It
does not need to mention a specific address, but may send some data.  I was
thinking of encoding it the same way as clwb, but using the currently
disallowed 11 (i.e., 3) combination of the mod/rm bits.  This generally
indicates a register as opposed to a memory operand.  I think I have found
more or less where to do this in the decoder, but if someone would respond
about that, it would be helpful.

Then there is the question of the other steps of adding an instruction, which
starts getting more mysterious (e.g., what does Iz, for example mean, and is
it what I want if I want this new instruction to have a register operand?).

It will seem I'll need to add a micro-op as well.  I can follow the clwb model
for that, except that this special thing will probably use some new flag in
its request/packet that will head toward the cache (and of course I will be
extending the cache to notice and handle that for the new thing I'm devising).

An overall sketch of how to accomplish this successfully and going with the
flow of the design would be great.  If there are specific pieces of
documentation I should be looking at it, pointers to them would also be
gratefully accepted.

Regards, and thanks in advance - Eliot Moss
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: 答复: Re: SPEC2017 in FS mode

[Liyichao via gem5-users]

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
时间： 2021-05-24 19:12:57

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-users [mailto:gem5-users@gem5.org]
> 发送时间: 2021年5月19日 19:09
> 收件人: gem5 users mailing list 
> 抄送: Hoa Nguyen 
> 主题: [gem5-users] Re: SPEC2017 in FS mode
>
> Hi Victor,
>
> I'm not sure what caused the errors of building the spec benchmarks.
>
> Also, I'm not sure how to prevent the vm from being closed after the builds
> fail. However, there are a few steps can be done to exterminate the disk
> image after the builds fail:
> - In the file src/spec-2017/disk-image/spec-2017/install-spec2017.sh,
> the last line "rm -f /home/gem5/spec2017/result/*" should be removed to keep
> the log generated by spec during benchmark compilation time.
> - When running packer, you can run "./packer build -on-error=abort
> spec-2017/spec-2017.json" to keep the disk image if the disk image building
> process fails.
> - After that, you can mount the disk image and check the log file generated
> by spec.
>
> packer fails due to "output directory already exists". In this case, you'll
> need to remove the "spec-2017/spec-2017-image" folder before starting packer
> again.
>
> Regards,
> Hoa Nguyen
>
> On 5/17/21, Victor Kariofillis via gem5-users  wrote:
>> Hi,
>>
>> I've tried running the SPEC2017 benchmarks in FS mode of gem5 using
>> the instructions/files provided by the gem5 resources page.
>>
>> https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stabl
>> e/src/spec-2017
>>
>> I've also followed the step by step instructions in the git repo for
>> gem5-art.
>>
>> https://github.com/darchr/gem5art-experiments/blob/master/README.md
>>
>> Everything works as intended until the benchmarks are supposed to be
>> built.
>> All of them fail with one of the two following errors:
>>
>> 1) Error with make!
>> 2) Error with fdo_make_pass1!
>>
>> First of all, why is this happening? Secondly, the vm closes after the
>> builds fail. I don't have the opportunity to check the make.out files
>> that have more information about the errors. Is there a way to prevent
>> the connection from closing or reopening it again? Running it again
>> with packer fails due to the directory existing already.
>>
>> I'd appreciate any help,
>> Victor
>>
> ___
> gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email
> to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: 答复: Re: SPEC2017 in FS mode

[Hoa Nguyen via gem5-users]

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's one.
More specifically, it will replace
gcc_dir = "/opt/rh/devtoolset-7/root/usr"
by
gcc_dir = "/usr"

However, in your SPEC 2017 disc, it comes with devtoolset-9 and not
devtoolset-7.

So, one way to fix that is to change "devtoolset-7" in the line 21 to
"devtoolset-9".

Regards,
Hoa Nguyen

On 5/20/21, Victor Kariofillis via gem5-users  wrote:
> Hi Hoa,
>
> Thanks for the help. I'm able now to look into why the builds fail.
>
> The gcc and gfortran commands are not found, which is weird since in
> *install-spec2017.sh* there is a command for installing them. In the
> terminal, I can clearly see that it is executed.
>
> qemu: build-essential is already the newest version (12.4ubuntu1).
>> qemu: gfortran is already the newest version (4:7.4.0-1ubuntu2.3).
>> qemu: 0 upgraded, 0 newly installed, 0 to remove and 176 not upgraded.
>>
>
> But when it's time to build spec benchmarks they fail.
>
> specmake: /opt/rh/devtoolset-9/root/usr/bin/gfortran: Command not found
>>
>
> Thanks
>
> On Thu, 20 May 2021 at 21:01, Liyichao via gem5-users 
> 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-users [mailto:gem5-users@gem5.org]
>> 发送时间: 2021年5月19日 19:09
>> 收件人: gem5 users mailing list 
>> 抄送: Hoa Nguyen 
>> 主题: [gem5-users] Re: SPEC2017 in FS mode
>>
>> Hi Victor,
>>
>> I'm not sure what caused the errors of building the spec benchmarks.
>>
>> Also, I'm not sure how to prevent the vm from being closed after the
>> builds fail. However, there are a few steps can be done to exterminate
>> the
>> disk image after the builds fail:
>> - In the file src/spec-2017/disk-image/spec-2017/install-spec2017.sh,
>> the last line "rm -f /home/gem5/spec2017/result/*" should be removed to
>> keep the log generated by spec during benchmark compilation time.
>> - When running packer, you can run "./packer build -on-error=abort
>> spec-2017/spec-2017.json" to keep the disk image if the disk image
>> building
>> process fails.
>> - After that, you can mount the disk image and check the log file
>> generated by spec.
>>
>> packer fails due to "output directory already exists". In this case,
>> you'll need to remove the "spec-2017/spec-2017-image" folder before
>> starting packer again.
>>
>> Regards,
>> Hoa Nguyen
>>
>> On 5/17/21, Victor Kariofillis via gem5-users 
>> wrote:
>> > Hi,
>> >
>> > I've tried running the SPEC2017 benchmarks in FS mode of gem5 using
>> > the instructions/files provided by the gem5 resources page.
>> >
>> > https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stabl
>> > e/src/spec-2017
>> >
>> > I've also followed the step by step instructions in the git repo for
>> > gem5-art.
>> >
>> > https://github.com/darchr/gem5art-experiments/blob/master/README.md
>> >
>> > Everything works as intended until the benchmarks are supposed to be
>> built.
>> > All of them fail with one of the two following errors:
>> >
>> > 1) Error with make!
>> > 2) Error with fdo_make_pass1!
>> >
>> > First of all, why is this happening? Secondly, the vm closes after the
>> > builds fail. I don't have the opportunity to check the make.out files
>> > that have more information about the errors. Is there a way to prevent
>> > the connection from closing or reopening it again? Running it again
>> > with packer fails due to the directory existing already.
>> >
>> > I'd appreciate any help,
>> > Victor
>> >
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an
>> email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: 答复: Re: SPEC2017 in FS mode

[Hoa Nguyen via gem5-users]

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-users [mailto:gem5-users@gem5.org]
> 发送时间: 2021年5月19日 19:09
> 收件人: gem5 users mailing list 
> 抄送: Hoa Nguyen 
> 主题: [gem5-users] Re: SPEC2017 in FS mode
>
> Hi Victor,
>
> I'm not sure what caused the errors of building the spec benchmarks.
>
> Also, I'm not sure how to prevent the vm from being closed after the builds
> fail. However, there are a few steps can be done to exterminate the disk
> image after the builds fail:
> - In the file src/spec-2017/disk-image/spec-2017/install-spec2017.sh,
> the last line "rm -f /home/gem5/spec2017/result/*" should be removed to keep
> the log generated by spec during benchmark compilation time.
> - When running packer, you can run "./packer build -on-error=abort
> spec-2017/spec-2017.json" to keep the disk image if the disk image building
> process fails.
> - After that, you can mount the disk image and check the log file generated
> by spec.
>
> packer fails due to "output directory already exists". In this case, you'll
> need to remove the "spec-2017/spec-2017-image" folder before starting packer
> again.
>
> Regards,
> Hoa Nguyen
>
> On 5/17/21, Victor Kariofillis via gem5-users  wrote:
>> Hi,
>>
>> I've tried running the SPEC2017 benchmarks in FS mode of gem5 using
>> the instructions/files provided by the gem5 resources page.
>>
>> https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stabl
>> e/src/spec-2017
>>
>> I've also followed the step by step instructions in the git repo for
>> gem5-art.
>>
>> https://github.com/darchr/gem5art-experiments/blob/master/README.md
>>
>> Everything works as intended until the benchmarks are supposed to be
>> built.
>> All of them fail with one of the two following errors:
>>
>> 1) Error with make!
>> 2) Error with fdo_make_pass1!
>>
>> First of all, why is this happening? Secondly, the vm closes after the
>> builds fail. I don't have the opportunity to check the make.out files
>> that have more information about the errors. Is there a way to prevent
>> the connection from closing or reopening it again? Running it again
>> with packer fails due to the directory existing already.
>>
>> I'd appreciate any help,
>> Victor
>>
> ___
> gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email
> to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s