[gem5-dev] Review Request 3800: x86 fix Mul1u instructions

2017-02-01 Thread Tony Gutierrez 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3800/
---

Review request for Default.


Repository: gem5


Description
---

Changeset 11970:a7fb935f1418
---
x86 fix Mul1u instructions

the Mul1uFlags and Mul1u instructions perform the 64b multiplication using
only 64b registers, however this method causes the high 64b to be corrupted
for certain inputs. to avoid this complexity, we use the compiler builtin
__uint128_t, which is supported by gcc and clang to simplify the code and
get correct results.


Diffs
-

  src/arch/x86/isa/microops/regop.isa ed89cb178ecd7586296d2a2e83595174474db554 

Diff: http://reviews.gem5.org/r/3800/diff/


Testing
---


Thanks,

Tony Gutierrez

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

Re: [gem5-dev] Compilation error for gem5 after statfs change

2017-02-01 Thread Matthias Jung 
Hi Bjoern,

on my MAC I run into the same issue:
http://qa.gem5.org//1905/compiling-problem-gem5-mac-os-10-11-6-scons-build-arm-gem5-opt


When I use your patch I run into some other errors:

In file included from build/ARM/arch/arm/linux/process.cc:56:
build/ARM/sim/syscall_emul.hh:545:41: error: no member named 'f_namemax' in 
'statfs'
tgt->f_namelen = TheISA::htog(host->f_namemax);
    ^
build/ARM/sim/syscall_emul.hh:551:34: error: no member named 'f_spare' in 
'statfs'
memcpy(>f_spare, >f_spare, sizeof(host->f_spare));
     ^
build/ARM/sim/syscall_emul.hh:551:56: error: no member named 'f_spare' in 
'statfs'
memcpy(>f_spare, >f_spare, sizeof(host->f_spare));
   ^
3 errors generated.
scons: *** [build/ARM/arch/arm/linux/process.o] Error 1
scons: building terminated because of errors.


If I can help somehow to fix it and get gem5 running on OSX again please let me 
know.


Regards
Matthias


> Am 25.01.2017 um 00:46 schrieb Bjoern A. Zeeb 
> :
> 
> On 24 Jan 2017, at 22:08, Jason Lowe-Power wrote:
> 
>> Hi Brandon,
>> 
>> I think this is a "real" bug:
>> http://qa.gem5.org//1905/compiling-problem-gem5-mac-os-10-11-6-scons-build-arm-gem5-opt.
>> I think there are a few more places that need an #ifdef NO_STATFS. Could
>> you look into it and post a patch if there's a problem? If not, please
>> reply to the gem5 QA post and let them know.
> 
> Can people try this one and probably get the #ifdefs right for NetBSD as 
> well?  There are at least 3 different checks for that code;  if people don’t 
> care about “style” I could get it right, but ..
> 
> diff -r e47703369039 src/sim/syscall_emul.hh
> --- a/src/sim/syscall_emul.hh   Fri Jan 20 14:12:58 2017 -0500
> +++ b/src/sim/syscall_emul.hh   Tue Jan 24 23:45:04 2017 +
> @@ -70,6 +70,8 @@
> #include 
> #if (NO_STATFS == 0)
> #include 
> +#else
> +#include 
> #endif
> #include 
> #include 
> @@ -530,20 +532,25 @@
> {
> TypedBufferArg tgt(addr);
> 
> +tgt->f_type = TheISA::htog(host->f_type);
> #if defined(__OpenBSD__) || defined(__APPLE__) || defined(__FreeBSD__)
> -tgt->f_type = 0;
> +tgt->f_bsize = TheISA::htog(host->f_iosize);
> #else
> -tgt->f_type = TheISA::htog(host->f_type);
> +tgt->f_bsize = TheISA::htog(host->f_bsize);
> #endif
> -tgt->f_bsize = TheISA::htog(host->f_bsize);
> tgt->f_blocks = TheISA::htog(host->f_blocks);
> tgt->f_bfree = TheISA::htog(host->f_bfree);
> tgt->f_bavail = TheISA::htog(host->f_bavail);
> tgt->f_files = TheISA::htog(host->f_files);
> tgt->f_ffree = TheISA::htog(host->f_ffree);
> memcpy(>f_fsid, >f_fsid, sizeof(host->f_fsid));
> +#if defined(__OpenBSD__) || defined(__APPLE__) || defined(__FreeBSD__)
> +tgt->f_namelen = TheISA::htog(host->f_namemax);
> +tgt->f_frsize = TheISA::htog(host->f_bsize);
> +#else
> tgt->f_namelen = TheISA::htog(host->f_namelen);
> tgt->f_frsize = TheISA::htog(host->f_frsize);
> +#endif
> memcpy(>f_spare, >f_spare, sizeof(host->f_spare));
> 
> tgt.copyOut(mem);
> ___
> 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 3798: misc: Clean up and complete the gem5<->SystemC-TLM bridge [9/6]

2017-02-01 Thread Christian Menard 


> On Jan. 31, 2017, 4:10 p.m., Jason Lowe-Power wrote:
> > I don't follow why you don't need to pay for the payload delay. Is that 
> > taken care of at some other point in the System-C model?
> 
> Christian Menard wrote:
> Simply paying for the payload delay in the transactor would be wrong. If 
> we look at how it works in gem5, then the port is not responsible for paying 
> for the header and payload delay. This is the responsibility of the receiving 
> SimObject. The transactors are just different implementations of gem5 ports. 
> Therefore, they should also not touch the header and payload delay and let 
> the receiving module handle the delay. However, in this case, the receiver is 
> a SystemC module that is not aware of the gem5 semantics, which makes it 
> complicated. If the transactor would pay for the full payload delay, then 
> this would mean that the transactor is an actual module that buffers all data 
> and waits for the end of the packet before forwarding it to the SystemC 
> world. However, the transactor should only translate between gem5 and TLM and 
> not influence the timing.
> 
> Let me explain a bit of the TLM protocol and how the transactors work:
> 
> The TLM base protocol is a four phase protocol (BEGIN_REQ, END_REQ, 
> BEGIN_RESP, END_RESP). When the slave port receives a packet from the gem5 
> world (recvTiningReq), it sends a BEGIN_REQ to the SyctemC world and blocks 
> the port. Upon receiving an END_REQ from the SystemC world, the port is 
> unblocked. When the port receives a BEGIN_RESP from the SystemC world it 
> sends a response packet to the gem5 world (sendTimingResp) and acknowledges 
> to the SystemC world by sending an END_RESP.
> 
> The BEGIN_REQUEST needs to be send exactly when the gem5 packet header 
> arrives at the transactor port. This is current time plus header delay. Then 
> the receiver (a SystemC module) is responsible for modelling the time 
> required for accepting all the data. This is simply done by sending the 
> END_REQ after a certain time. Asuming that the request carries data, the time 
> for transporting this data is modeled by the receiver. It simply delays the 
> END_REQ for a certain amount of time. If we assume that the SystemC module 
> that receives the request, can handle incoming data at lower or the same 
> speed as the XBar, everything should work fine. If the XBar is limiting the 
> speed of data transport, then yes, actually we should pay for the payload 
> delay somewhere. However, I don't have a solution for this problem.
> 
> Maybe someone has any suggestions?
> 
> Jason Lowe-Power wrote:
> Thanks for the explanation. I think I understand now. I think this is a 
> perfectly fine solution, but it would be helpful if you included a little 
> more detail in your comment. Maybe something like "We throw away the payload 
> delay and expect the System-C object to be responsible for modeling this 
> delay. This can lead to incorrect delays if the X-Bar's payload delay is 
> longer than than the System-C module's delay between BEGIN_REQ and END_REQ". 
> Feel free to modify this to make it more clear, of course.
> 
> Another option, if you feel like implementing it (and don't feel any 
> pressure to do this), is to save the payload delay and then check to see if 
> it matches the delay between BEGIN_REQ and END_REQ. If it doesn't match (or 
> at least if it is higher), then you could issue a "warn(...)". 
> 
> I think it's important to document this as one of the intricacies of the 
> gem5-System-C bindings, but other than adding something to the comment, I'm 
> happy with this patch.

Yes, I agree, its very important to document this. I updated the patch and hope 
it is clearer now.

I had the same idea about the warning, I will see if I manage to implement this.


- Christian


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3798/#review9355
---


On Feb. 1, 2017, 5:57 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3798/
> ---
> 
> (Updated Feb. 1, 2017, 5:57 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11802:31b809f6c634
> ---
> misc: Clean up and complete the gem5<->SystemC-TLM bridge [9/6]
> 
> The current TLM bridge only provides a Slave Port that allows the gem5 world 
> to
> send request to the SystemC world. This patch series refractors and cleans up
> the existing code, and adds a Master Port that allows the SystemC world to 
> send
> requests to the gem5 world.
> 
> This patch:
>   * Pay for the header delay that the gem5 XBar annotates

Re: [gem5-dev] Review Request 3799: misc: Clean up and complete the gem5<->SystemC-TLM bridge [10/6]

2017-02-01 Thread Christian Menard 


> On Jan. 31, 2017, 4:14 p.m., Jason Lowe-Power wrote:
> > How does this relate to init/initState/startup for SimObjects 
> > (http://gem5.org/SimObject_Initialization)? I'm not very familiar with the 
> > System-C bindings. Does this object live fully in the System-C world?

Yes, this object is a pure SystemC object. It derives from Gem5SystemC::Module 
defined in util/systemc/sc_module.hh which in turn is a sc_module (or 
sc_channel with patch 3774). SystemC has a buit-in mechanism for callbacks 
before and after the SystemC-simulation. However, I find it very useful to have 
hooks at the beginning and end of the gem5 simulation in SystemC.


- Christian


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3799/#review9356
---


On Jan. 31, 2017, 10:58 a.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3799/
> ---
> 
> (Updated Jan. 31, 2017, 10:58 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11803:ee5f72396d89
> ---
> misc: Clean up and complete the gem5<->SystemC-TLM bridge [10/6]
> 
> The current TLM bridge only provides a Slave Port that allows the gem5 world 
> to
> send request to the SystemC world. This patch series refractors and cleans up
> the existing code, and adds a Master Port that allows the SystemC world to 
> send
> requests to the gem5 world.
> 
> This patch:
>   * Add callbacks for the Gem5SimControl that are called at before and after
> simulate()
> 
> 
> Diffs
> -
> 
>   util/tlm/sim_control.hh PRE-CREATION 
>   util/tlm/sim_control.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3799/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

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

Re: [gem5-dev] Review Request 3798: misc: Clean up and complete the gem5<->SystemC-TLM bridge [9/6]

2017-02-01 Thread Jason Lowe-Power 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3798/#review9364
---

Ship it!


Ship It!

- Jason Lowe-Power


On Jan. 30, 2017, 4:40 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3798/
> ---
> 
> (Updated Jan. 30, 2017, 4:40 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11802:93cbf8202c63
> ---
> misc: Clean up and complete the gem5<->SystemC-TLM bridge [9/6]
> 
> The current TLM bridge only provides a Slave Port that allows the gem5 world 
> to
> send request to the SystemC world. This patch series refractors and cleans up
> the existing code, and adds a Master Port that allows the SystemC world to 
> send
> requests to the gem5 world.
> 
> This patch:
>   * Pay the header delay that the gem5 XBar annotates to packets.
> 
> 
> Diffs
> -
> 
>   util/tlm/sc_master_port.cc PRE-CREATION 
>   util/tlm/sc_slave_port.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3798/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

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

Re: [gem5-dev] Review Request 3798: misc: Clean up and complete the gem5<->SystemC-TLM bridge [9/6]

2017-02-01 Thread Jason Lowe-Power 


> On Jan. 31, 2017, 4:10 p.m., Jason Lowe-Power wrote:
> > I don't follow why you don't need to pay for the payload delay. Is that 
> > taken care of at some other point in the System-C model?
> 
> Christian Menard wrote:
> Simply paying for the payload delay in the transactor would be wrong. If 
> we look at how it works in gem5, then the port is not responsible for paying 
> for the header and payload delay. This is the responsibility of the receiving 
> SimObject. The transactors are just different implementations of gem5 ports. 
> Therefore, they should also not touch the header and payload delay and let 
> the receiving module handle the delay. However, in this case, the receiver is 
> a SystemC module that is not aware of the gem5 semantics, which makes it 
> complicated. If the transactor would pay for the full payload delay, then 
> this would mean that the transactor is an actual module that buffers all data 
> and waits for the end of the packet before forwarding it to the SystemC 
> world. However, the transactor should only translate between gem5 and TLM and 
> not influence the timing.
> 
> Let me explain a bit of the TLM protocol and how the transactors work:
> 
> The TLM base protocol is a four phase protocol (BEGIN_REQ, END_REQ, 
> BEGIN_RESP, END_RESP). When the slave port receives a packet from the gem5 
> world (recvTiningReq), it sends a BEGIN_REQ to the SyctemC world and blocks 
> the port. Upon receiving an END_REQ from the SystemC world, the port is 
> unblocked. When the port receives a BEGIN_RESP from the SystemC world it 
> sends a response packet to the gem5 world (sendTimingResp) and acknowledges 
> to the SystemC world by sending an END_RESP.
> 
> The BEGIN_REQUEST needs to be send exactly when the gem5 packet header 
> arrives at the transactor port. This is current time plus header delay. Then 
> the receiver (a SystemC module) is responsible for modelling the time 
> required for accepting all the data. This is simply done by sending the 
> END_REQ after a certain time. Asuming that the request carries data, the time 
> for transporting this data is modeled by the receiver. It simply delays the 
> END_REQ for a certain amount of time. If we assume that the SystemC module 
> that receives the request, can handle incoming data at lower or the same 
> speed as the XBar, everything should work fine. If the XBar is limiting the 
> speed of data transport, then yes, actually we should pay for the payload 
> delay somewhere. However, I don't have a solution for this problem.
> 
> Maybe someone has any suggestions?

Thanks for the explanation. I think I understand now. I think this is a 
perfectly fine solution, but it would be helpful if you included a little more 
detail in your comment. Maybe something like "We throw away the payload delay 
and expect the System-C object to be responsible for modeling this delay. This 
can lead to incorrect delays if the X-Bar's payload delay is longer than than 
the System-C module's delay between BEGIN_REQ and END_REQ". Feel free to modify 
this to make it more clear, of course.

Another option, if you feel like implementing it (and don't feel any pressure 
to do this), is to save the payload delay and then check to see if it matches 
the delay between BEGIN_REQ and END_REQ. If it doesn't match (or at least if it 
is higher), then you could issue a "warn(...)". 

I think it's important to document this as one of the intricacies of the 
gem5-System-C bindings, but other than adding something to the comment, I'm 
happy with this patch.


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3798/#review9355
---


On Jan. 30, 2017, 4:40 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3798/
> ---
> 
> (Updated Jan. 30, 2017, 4:40 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11802:93cbf8202c63
> ---
> misc: Clean up and complete the gem5<->SystemC-TLM bridge [9/6]
> 
> The current TLM bridge only provides a Slave Port that allows the gem5 world 
> to
> send request to the SystemC world. This patch series refractors and cleans up
> the existing code, and adds a Master Port that allows the SystemC world to 
> send
> requests to the gem5 world.
> 
> This patch:
>   * Pay the header delay that the gem5 XBar annotates to packets.
> 
> 
> Diffs
> -
> 
>   util/tlm/sc_master_port.cc PRE-CREATION 
>   util/tlm/sc_slave_port.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3798/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

Re: [gem5-dev] Review Request 3796: misc: Clean up and complete the gem5<->SystemC-TLM bridge [7/6]

2017-02-01 Thread Andreas Hansson 


> On Feb. 1, 2017, 1:29 p.m., Andreas Hansson wrote:
> > It would be tremendously helpful if we could get some regressions tests, 
> > but until core SystemC is available with Apache v2 (which supposedly should 
> > happen) I do not see a good way. Any thoughts?

Actually, I noticed that the systemc2.3.1a download is actually updated to 
Apache v2. I am tempted to suggest we include it in gem5's ext/ directory, 
which would also enable us to integrate the systemc builds into regressions.

What do you think? Is anyone happy to give it a go?


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3796/#review9361
---


On Jan. 30, 2017, 4:13 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3796/
> ---
> 
> (Updated Jan. 30, 2017, 4:13 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11800:b5ad6c483119
> ---
> misc: Clean up and complete the gem5<->SystemC-TLM bridge [7/6]
> 
> The current TLM bridge only provides a Slave Port that allows the gem5 world 
> to
> send request to the SystemC world. This patch series refractors and cleans up
> the existing code, and adds a Master Port that allows the SystemC world to 
> send
> requests to the gem5 world.
> 
> This patch:
>  * Implement 'pipe through' for gem5 Packets (see explanation below)
> 
> Basically, this patch ensures that all transactions that originated in the 
> gem5
> world are converted back to the original packet when entering the gem5 world.
> So far, this only worked for packets that are responded to by a SyctemC
> component (e.g. when a gem5 CPU sends a request to a SystemC memory). By
> implementing the 'pipe through' this patch ensures, that packets that are
> responded to by a gem5 component (e.g. when a gem5 CPU sends a request to a
> gem5 memory via a SystemC interconnect) are handled properly.
> 
> 
> Diffs
> -
> 
>   util/tlm/sc_ext.hh c10c50cb8ac9 
>   util/tlm/sc_ext.cc c10c50cb8ac9 
>   util/tlm/sc_master_port.hh PRE-CREATION 
>   util/tlm/sc_master_port.cc PRE-CREATION 
>   util/tlm/sc_slave_port.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3796/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

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

Re: [gem5-dev] Review Request 3798: misc: Clean up and complete the gem5<->SystemC-TLM bridge [9/6]

2017-02-01 Thread Christian Menard 


> On Jan. 31, 2017, 4:10 p.m., Jason Lowe-Power wrote:
> > I don't follow why you don't need to pay for the payload delay. Is that 
> > taken care of at some other point in the System-C model?

Simply paying for the payload delay in the transactor would be wrong. If we 
look at how it works in gem5, then the port is not responsible for paying for 
the header and payload delay. This is the responsibility of the receiving 
SimObject. The transactors are just different implementations of gem5 ports. 
Therefore, they should also not touch the header and payload delay and let the 
receiving module handle the delay. However, in this case, the receiver is a 
SystemC module that is not aware of the gem5 semantics, which makes it 
complicated. If the transactor would pay for the full payload delay, then this 
would mean that the transactor is an actual module that buffers all data and 
waits for the end of the packet before forwarding it to the SystemC world. 
However, the transactor should only translate between gem5 and TLM and not 
influence the timing.

Let me explain a bit of the TLM protocol and how the transactors work:

The TLM base protocol is a four phase protocol (BEGIN_REQ, END_REQ, BEGIN_RESP, 
END_RESP). When the slave port receives a packet from the gem5 world 
(recvTiningReq), it sends a BEGIN_REQ to the SyctemC world and blocks the port. 
Upon receiving an END_REQ from the SystemC world, the port is unblocked. When 
the port receives a BEGIN_RESP from the SystemC world it sends a response 
packet to the gem5 world (sendTimingResp) and acknowledges to the SystemC world 
by sending an END_RESP.

The BEGIN_REQUEST needs to be send exactly when the gem5 packet header arrives 
at the transactor port. This is current time plus header delay. Then the 
receiver (a SystemC module) is responsible for modelling the time required for 
accepting all the data. This is simply done by sending the END_REQ after a 
certain time. Asuming that the request carries data, the time for transporting 
this data is modeled by the receiver. It simply delays the END_REQ for a 
certain amount of time. If we assume that the SystemC module that receives the 
request, can handle incoming data at lower or the same speed as the XBar, 
everything should work fine. If the XBar is limiting the speed of data 
transport, then yes, actually we should pay for the payload delay somewhere. 
However, I don't have a solution for this problem.

Maybe someone has any suggestions?


- Christian


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3798/#review9355
---


On Jan. 30, 2017, 4:40 p.m., Christian Menard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3798/
> ---
> 
> (Updated Jan. 30, 2017, 4:40 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11802:93cbf8202c63
> ---
> misc: Clean up and complete the gem5<->SystemC-TLM bridge [9/6]
> 
> The current TLM bridge only provides a Slave Port that allows the gem5 world 
> to
> send request to the SystemC world. This patch series refractors and cleans up
> the existing code, and adds a Master Port that allows the SystemC world to 
> send
> requests to the gem5 world.
> 
> This patch:
>   * Pay the header delay that the gem5 XBar annotates to packets.
> 
> 
> Diffs
> -
> 
>   util/tlm/sc_master_port.cc PRE-CREATION 
>   util/tlm/sc_slave_port.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3798/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Christian Menard
> 
>

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

Re: [gem5-dev] Review Request 3378: scons: make build better on FreeBSD

2017-02-01 Thread Andreas Hansson 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3378/#review9358
---



SConstruct (line 1097)


Before committing this, could you add a comment before this line to explain 
that is is for BSD?


- Andreas Hansson


On Jan. 31, 2017, 1:44 p.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3378/
> ---
> 
> (Updated Jan. 31, 2017, 1:44 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> scons: make build better on FreeBSD
> 
> Various changes we found needed to build gem5 successfully on
> FreeBSD.
> 
> 
> Diffs
> -
> 
>   SConstruct e47703369039 
> 
> Diff: http://reviews.gem5.org/r/3378/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

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