Re: [m5-dev] Review Request: SCons: Clean up some inconsistent capitalization in scons options.

[nathan binkert]

Do the regression scripts need to be fixed?

On Mon, Feb 28, 2011 at 11:59 AM, Ali Saidi  wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/522/
>
> Ship it!
>
> Looks fine. Two things though: 1) The documentation on the wiki needs to be 
> updated along with this change. 2) I would like a separate email sent to the 
> list saying that update_refs -> UPDATE_REFS.
>
>
> - Ali
>
> On February 28th, 2011, 4:54 a.m., Gabe Black wrote:
>   Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
> By Gabe Black.
>
> *Updated 2011-02-28 04:54:41*
> Description
>
> SCons: Clean up some inconsistent capitalization in scons options.
>
>   Diffs
>
>- SConstruct (c6ba129c2764)
>- src/mem/protocol/SConsopts (c6ba129c2764)
>- tests/SConscript (c6ba129c2764)
>
> View Diff 
>
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Multiple inheritance, sim objects, and swig

[Steve Reinhardt]

Yea, double inheritance from SimObjects seems like an obviously bad idea to
me.

I think part of the problem is that we don't always expose the entire C++
hierarchy to swig just for simplicity, and if some of those "hidden" classes
have multiple base classes then swig could get confused.  If this really is
the problem, then exposing more of the C++ to swig should in theory fix it.

I just noticed recently that I've been getting these warnings:

build/ALPHA_SE/sim/eventq.hh:64: Warning(401): Base class 'Serializable'
ignored - unknown module name for base. Either import the appropriate module
interface file or specify the name of the module in the %import directive.
build/ALPHA_SE/sim/eventq.hh:64: Warning(401): Base class 'FastAlloc'
ignored - unknown module name for base. Either import the appropriate module
interface file or specify the name of the module in the %import directive.
build/ALPHA_SE/sim/eventq.hh:365: Warning(401): Base class 'Serializable'
ignored - unknown module name for base. Either import the appropriate module
interface file or specify the name of the module in the %import directive.

I don't know if that's related or not.

Nate has the most experience with swig, so I'd wait and see what he knows
about this before spending a lot of time on it.

Steve

On Mon, Feb 28, 2011 at 12:51 PM, Ali Saidi  wrote:

>
> One was a SimObject and one was a random other class. I'm 99.9% certain to
> SimObjects will behave very badly.
>
> Ali
>
>
> On Mon, 28 Feb 2011 12:44:03 -0800, Gabe Black 
> wrote:
>
>> Were the two base classes both SimObjects and present in python? That
>> might help things work. Only one was a SimObject in my case. Having two
>> SimObjects seems relatively dangerous too since they might not be
>> handled in the same order. Even if they are, are they guaranteed to be
>> compatible? I'm not sure.
>>
>> Gabe
>>
>> On 02/28/11 12:30, Ali Saidi wrote:
>>
>>>
>>> I had this happen with multiple inheritance in the classes that
>>> support being a VncMouse or VncKeyboard. It drove me nuts trying to
>>> figure out what was going on but rebuilding from a clean copy solved
>>> the problem, so I think there is some weird behavior going on. I
>>> couldn't figure out it because it seemed like the code was all being
>>> recompiled.
>>>
>>> Ali
>>>
>>>
>>>
>>> On Mon, 28 Feb 2011 11:55:56 -0800, Gabe Black 
>>> wrote:
>>>
 Yes, it's possible. I've run into those problems before as well, and I
 fought with this bug for long enough that I think I would have tried
 building from scratch, but I don't remember for sure. Assuming I don't
 set it aside and forgot about it after sending this email, I'll see if I
 can get it the problem to happen again.

 Gabe

 On 02/28/11 06:22, Ali Saidi wrote:

> I think that this actually works ok, but perhaps you changed the
> hierarchy in python while you were doing this?  I've run into a
> similar problem with scons not rebuilding the params structs after
> some changes which led to very odd behavior. Is it possible that
> this is the cause?
>
> Ali
>
> Sent from my ARM powered device
>
> On Feb 28, 2011, at 5:48 AM, Gabe Black  wrote:
>
>  I ran into a problem a while back where the python and C++ versions
>> of a
>> simobject I was working with weren't meshing with each other, and
>> M5 was
>> segfaulting out and crashing. I worked around the problem and intended
>> to mention this to the list, but I haven't gotten around to it
>> until now.
>>
>> Basically, the python version of the simobject had just one base, I
>> believe, which wasn't very interesting. I think it may have simply
>> been
>> SimObject. On the C++ side, however, the object inherited from
>> whatever
>> SimObject was appropriate, but then also another class that had an
>> interface and some functionality I wanted to have in my SimObject.
>> When
>> some infrastructure code tried to call init() on a new simobject of
>> this
>> type, what actually happened was that a destructor was called for
>> one of
>> the base classes. M5 then burst into flames died.
>>
>> I think the issue is that the python wrapper stuff builds up a
>> parallel
>> object hierarchy that mirrors the python stuff which is supposed to
>> mirror the C++ stuff. When manipulating pointers to the classes
>> defined
>> in regular C++, swig thinks it's manipulating pointers to it's
>> parallel
>> version of C++. That works fine when only single inheritance is
>> used and
>> pointers are always equal to each other (I think they are, at least),
>> but that breaks down when multiple inheritance is being used. I think
>> what happened was that the vtable pointer for the SimObject subobject
>> was not at the lowest addresses of the inheriting subclass. When swig
>> used a reinterpret_cast on the pointer it go

Re: [m5-dev] Multiple inheritance, sim objects, and swig

[Ali Saidi]

One was a SimObject and one was a random other class. I'm 99.9% certain 
to SimObjects will behave very badly.


Ali

On Mon, 28 Feb 2011 12:44:03 -0800, Gabe Black  
wrote:

Were the two base classes both SimObjects and present in python? That
might help things work. Only one was a SimObject in my case. Having 
two

SimObjects seems relatively dangerous too since they might not be
handled in the same order. Even if they are, are they guaranteed to 
be

compatible? I'm not sure.

Gabe

On 02/28/11 12:30, Ali Saidi wrote:


I had this happen with multiple inheritance in the classes that
support being a VncMouse or VncKeyboard. It drove me nuts trying to
figure out what was going on but rebuilding from a clean copy solved
the problem, so I think there is some weird behavior going on. I
couldn't figure out it because it seemed like the code was all being
recompiled.

Ali



On Mon, 28 Feb 2011 11:55:56 -0800, Gabe Black 


wrote:
Yes, it's possible. I've run into those problems before as well, 
and I
fought with this bug for long enough that I think I would have 
tried
building from scratch, but I don't remember for sure. Assuming I 
don't
set it aside and forgot about it after sending this email, I'll see 
if I

can get it the problem to happen again.

Gabe

On 02/28/11 06:22, Ali Saidi wrote:

I think that this actually works ok, but perhaps you changed the
hierarchy in python while you were doing this?  I've run into a
similar problem with scons not rebuilding the params structs after
some changes which led to very odd behavior. Is it possible that
this is the cause?

Ali

Sent from my ARM powered device

On Feb 28, 2011, at 5:48 AM, Gabe Black  
wrote:


I ran into a problem a while back where the python and C++ 
versions

of a
simobject I was working with weren't meshing with each other, and
M5 was
segfaulting out and crashing. I worked around the problem and 
intended

to mention this to the list, but I haven't gotten around to it
until now.

Basically, the python version of the simobject had just one base, 
I
believe, which wasn't very interesting. I think it may have 
simply

been
SimObject. On the C++ side, however, the object inherited from
whatever
SimObject was appropriate, but then also another class that had 
an
interface and some functionality I wanted to have in my 
SimObject.

When
some infrastructure code tried to call init() on a new simobject 
of

this
type, what actually happened was that a destructor was called for
one of
the base classes. M5 then burst into flames died.

I think the issue is that the python wrapper stuff builds up a
parallel
object hierarchy that mirrors the python stuff which is supposed 
to

mirror the C++ stuff. When manipulating pointers to the classes
defined
in regular C++, swig thinks it's manipulating pointers to it's
parallel
version of C++. That works fine when only single inheritance is
used and
pointers are always equal to each other (I think they are, at 
least),
but that breaks down when multiple inheritance is being used. I 
think
what happened was that the vtable pointer for the SimObject 
subobject
was not at the lowest addresses of the inheriting subclass. When 
swig
used a reinterpret_cast on the pointer it got back from the 
create

function (that's what I remember it did, at least) it ended up
referring
to whatever vtable pointer actually was there, which I suppose 
was for
either the other class or for the subclass itself. This meant 
that

when
it tried to call virtual function X which it expected to be init, 
it

actually called function X in the wrong type of table which was
really a
destructor.

I spent a few minutes on a couple of occasions thinking about a 
way to
handle all this that avoids this problem, but I didn't really 
think of
anything. Things are generally they way they are because they 
need

to be
for one reason or another, and it's not apparent how to change
things in
a way that's not extremely obnoxious or destructive that covers 
this
case as well. In any case, I thought it was important to mention 
I hit
this issue even if I didn't have a way to fix it. I don't have 
the

code
around any more that was breaking, but I expect it wouldn't be 
that

hard
to reproduce.

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


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


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


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


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


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

Re: [m5-dev] Multiple inheritance, sim objects, and swig

[Gabe Black]

Were the two base classes both SimObjects and present in python? That
might help things work. Only one was a SimObject in my case. Having two
SimObjects seems relatively dangerous too since they might not be
handled in the same order. Even if they are, are they guaranteed to be
compatible? I'm not sure.

Gabe

On 02/28/11 12:30, Ali Saidi wrote:
>
> I had this happen with multiple inheritance in the classes that
> support being a VncMouse or VncKeyboard. It drove me nuts trying to
> figure out what was going on but rebuilding from a clean copy solved
> the problem, so I think there is some weird behavior going on. I
> couldn't figure out it because it seemed like the code was all being
> recompiled.
>
> Ali
>
>
>
> On Mon, 28 Feb 2011 11:55:56 -0800, Gabe Black 
> wrote:
>> Yes, it's possible. I've run into those problems before as well, and I
>> fought with this bug for long enough that I think I would have tried
>> building from scratch, but I don't remember for sure. Assuming I don't
>> set it aside and forgot about it after sending this email, I'll see if I
>> can get it the problem to happen again.
>>
>> Gabe
>>
>> On 02/28/11 06:22, Ali Saidi wrote:
>>> I think that this actually works ok, but perhaps you changed the
>>> hierarchy in python while you were doing this?  I've run into a
>>> similar problem with scons not rebuilding the params structs after
>>> some changes which led to very odd behavior. Is it possible that
>>> this is the cause?
>>>
>>> Ali
>>>
>>> Sent from my ARM powered device
>>>
>>> On Feb 28, 2011, at 5:48 AM, Gabe Black  wrote:
>>>
 I ran into a problem a while back where the python and C++ versions
 of a
 simobject I was working with weren't meshing with each other, and
 M5 was
 segfaulting out and crashing. I worked around the problem and intended
 to mention this to the list, but I haven't gotten around to it
 until now.

 Basically, the python version of the simobject had just one base, I
 believe, which wasn't very interesting. I think it may have simply
 been
 SimObject. On the C++ side, however, the object inherited from
 whatever
 SimObject was appropriate, but then also another class that had an
 interface and some functionality I wanted to have in my SimObject.
 When
 some infrastructure code tried to call init() on a new simobject of
 this
 type, what actually happened was that a destructor was called for
 one of
 the base classes. M5 then burst into flames died.

 I think the issue is that the python wrapper stuff builds up a
 parallel
 object hierarchy that mirrors the python stuff which is supposed to
 mirror the C++ stuff. When manipulating pointers to the classes
 defined
 in regular C++, swig thinks it's manipulating pointers to it's
 parallel
 version of C++. That works fine when only single inheritance is
 used and
 pointers are always equal to each other (I think they are, at least),
 but that breaks down when multiple inheritance is being used. I think
 what happened was that the vtable pointer for the SimObject subobject
 was not at the lowest addresses of the inheriting subclass. When swig
 used a reinterpret_cast on the pointer it got back from the create
 function (that's what I remember it did, at least) it ended up
 referring
 to whatever vtable pointer actually was there, which I suppose was for
 either the other class or for the subclass itself. This meant that
 when
 it tried to call virtual function X which it expected to be init, it
 actually called function X in the wrong type of table which was
 really a
 destructor.

 I spent a few minutes on a couple of occasions thinking about a way to
 handle all this that avoids this problem, but I didn't really think of
 anything. Things are generally they way they are because they need
 to be
 for one reason or another, and it's not apparent how to change
 things in
 a way that's not extremely obnoxious or destructive that covers this
 case as well. In any case, I thought it was important to mention I hit
 this issue even if I didn't have a way to fix it. I don't have the
 code
 around any more that was breaking, but I expect it wouldn't be that
 hard
 to reproduce.

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

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

_

Re: [m5-dev] Multiple inheritance, sim objects, and swig

[Ali Saidi]

I had this happen with multiple inheritance in the classes that support 
being a VncMouse or VncKeyboard. It drove me nuts trying to figure out 
what was going on but rebuilding from a clean copy solved the problem, 
so I think there is some weird behavior going on. I couldn't figure out 
it because it seemed like the code was all being recompiled.


Ali



On Mon, 28 Feb 2011 11:55:56 -0800, Gabe Black  
wrote:
Yes, it's possible. I've run into those problems before as well, and 
I

fought with this bug for long enough that I think I would have tried
building from scratch, but I don't remember for sure. Assuming I 
don't
set it aside and forgot about it after sending this email, I'll see 
if I

can get it the problem to happen again.

Gabe

On 02/28/11 06:22, Ali Saidi wrote:
I think that this actually works ok, but perhaps you changed the 
hierarchy in python while you were doing this?  I've run into a 
similar problem with scons not rebuilding the params structs after 
some changes which led to very odd behavior. Is it possible that this 
is the cause?


Ali

Sent from my ARM powered device

On Feb 28, 2011, at 5:48 AM, Gabe Black  
wrote:


I ran into a problem a while back where the python and C++ versions 
of a
simobject I was working with weren't meshing with each other, and 
M5 was
segfaulting out and crashing. I worked around the problem and 
intended
to mention this to the list, but I haven't gotten around to it 
until now.


Basically, the python version of the simobject had just one base, I
believe, which wasn't very interesting. I think it may have simply 
been
SimObject. On the C++ side, however, the object inherited from 
whatever

SimObject was appropriate, but then also another class that had an
interface and some functionality I wanted to have in my SimObject. 
When
some infrastructure code tried to call init() on a new simobject of 
this
type, what actually happened was that a destructor was called for 
one of

the base classes. M5 then burst into flames died.

I think the issue is that the python wrapper stuff builds up a 
parallel

object hierarchy that mirrors the python stuff which is supposed to
mirror the C++ stuff. When manipulating pointers to the classes 
defined
in regular C++, swig thinks it's manipulating pointers to it's 
parallel
version of C++. That works fine when only single inheritance is 
used and
pointers are always equal to each other (I think they are, at 
least),
but that breaks down when multiple inheritance is being used. I 
think
what happened was that the vtable pointer for the SimObject 
subobject
was not at the lowest addresses of the inheriting subclass. When 
swig

used a reinterpret_cast on the pointer it got back from the create
function (that's what I remember it did, at least) it ended up 
referring
to whatever vtable pointer actually was there, which I suppose was 
for
either the other class or for the subclass itself. This meant that 
when
it tried to call virtual function X which it expected to be init, 
it
actually called function X in the wrong type of table which was 
really a

destructor.

I spent a few minutes on a couple of occasions thinking about a way 
to
handle all this that avoids this problem, but I didn't really think 
of
anything. Things are generally they way they are because they need 
to be
for one reason or another, and it's not apparent how to change 
things in
a way that's not extremely obnoxious or destructive that covers 
this
case as well. In any case, I thought it was important to mention I 
hit
this issue even if I didn't have a way to fix it. I don't have the 
code
around any more that was breaking, but I expect it wouldn't be that 
hard

to reproduce.

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


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


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


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

Re: [m5-dev] Review Request: Ruby: Mention that Ruby's bound checking option only applies to Ruby.

[Ali Saidi]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/523/#review919
---

Ship it!


- Ali


On 2011-02-28 04:54:57, Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/523/
> ---
> 
> (Updated 2011-02-28 04:54:57)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> Ruby: Mention that Ruby's bound checking option only applies to Ruby.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/SConsopts c6ba129c2764 
> 
> Diff: http://reviews.m5sim.org/r/523/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabe
> 
>

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

Re: [m5-dev] Review Request: SCons: Separately label the global non-sticky options.

[Ali Saidi]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/524/#review918
---

Ship it!


- Ali


On 2011-02-28 04:55:46, Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/524/
> ---
> 
> (Updated 2011-02-28 04:55:46)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> SCons: Separately label the global non-sticky options.
> 
> The global sticky options were being printed with a heading, and then the
> global nonsticky options were being printed immediately after them without a
> heading. Because the two lists ran together and the first had its own heading,
> it looked like -all- those options where sticky even though some of them
> aren't. This change adds a label to the second list so it's clear they're
> different.
> 
> 
> Diffs
> -
> 
>   SConstruct c6ba129c2764 
> 
> Diff: http://reviews.m5sim.org/r/524/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabe
> 
>

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

Re: [m5-dev] Review Request: SCons: Clean up some inconsistent capitalization in scons options.

[Ali Saidi]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/522/#review917
---

Ship it!


Looks fine. Two things though: 1) The documentation on the wiki needs to be 
updated along with this change. 2) I would like a separate email sent to the 
list saying that update_refs -> UPDATE_REFS. 

- Ali


On 2011-02-28 04:54:41, Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/522/
> ---
> 
> (Updated 2011-02-28 04:54:41)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> SCons: Clean up some inconsistent capitalization in scons options.
> 
> 
> Diffs
> -
> 
>   SConstruct c6ba129c2764 
>   src/mem/protocol/SConsopts c6ba129c2764 
>   tests/SConscript c6ba129c2764 
> 
> Diff: http://reviews.m5sim.org/r/522/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabe
> 
>

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

Re: [m5-dev] Multiple inheritance, sim objects, and swig

[Gabe Black]

Yes, it's possible. I've run into those problems before as well, and I
fought with this bug for long enough that I think I would have tried
building from scratch, but I don't remember for sure. Assuming I don't
set it aside and forgot about it after sending this email, I'll see if I
can get it the problem to happen again.

Gabe

On 02/28/11 06:22, Ali Saidi wrote:
> I think that this actually works ok, but perhaps you changed the hierarchy in 
> python while you were doing this?  I've run into a similar problem with scons 
> not rebuilding the params structs after some changes which led to very odd 
> behavior. Is it possible that this is the cause?
>
> Ali
>
> Sent from my ARM powered device
>
> On Feb 28, 2011, at 5:48 AM, Gabe Black  wrote:
>
>> I ran into a problem a while back where the python and C++ versions of a
>> simobject I was working with weren't meshing with each other, and M5 was
>> segfaulting out and crashing. I worked around the problem and intended
>> to mention this to the list, but I haven't gotten around to it until now.
>>
>> Basically, the python version of the simobject had just one base, I
>> believe, which wasn't very interesting. I think it may have simply been
>> SimObject. On the C++ side, however, the object inherited from whatever
>> SimObject was appropriate, but then also another class that had an
>> interface and some functionality I wanted to have in my SimObject. When
>> some infrastructure code tried to call init() on a new simobject of this
>> type, what actually happened was that a destructor was called for one of
>> the base classes. M5 then burst into flames died.
>>
>> I think the issue is that the python wrapper stuff builds up a parallel
>> object hierarchy that mirrors the python stuff which is supposed to
>> mirror the C++ stuff. When manipulating pointers to the classes defined
>> in regular C++, swig thinks it's manipulating pointers to it's parallel
>> version of C++. That works fine when only single inheritance is used and
>> pointers are always equal to each other (I think they are, at least),
>> but that breaks down when multiple inheritance is being used. I think
>> what happened was that the vtable pointer for the SimObject subobject
>> was not at the lowest addresses of the inheriting subclass. When swig
>> used a reinterpret_cast on the pointer it got back from the create
>> function (that's what I remember it did, at least) it ended up referring
>> to whatever vtable pointer actually was there, which I suppose was for
>> either the other class or for the subclass itself. This meant that when
>> it tried to call virtual function X which it expected to be init, it
>> actually called function X in the wrong type of table which was really a
>> destructor.
>>
>> I spent a few minutes on a couple of occasions thinking about a way to
>> handle all this that avoids this problem, but I didn't really think of
>> anything. Things are generally they way they are because they need to be
>> for one reason or another, and it's not apparent how to change things in
>> a way that's not extremely obnoxious or destructive that covers this
>> case as well. In any case, I thought it was important to mention I hit
>> this issue even if I didn't have a way to fix it. I don't have the code
>> around any more that was breaking, but I expect it wouldn't be that hard
>> to reproduce.
>>
>> Gabe
>> ___
>> m5-dev mailing list
>> m5-dev@m5sim.org
>> http://m5sim.org/mailman/listinfo/m5-dev
>>
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev

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

Re: [m5-dev] Multiple inheritance, sim objects, and swig

[Ali Saidi]

I think that this actually works ok, but perhaps you changed the hierarchy in 
python while you were doing this?  I've run into a similar problem with scons 
not rebuilding the params structs after some changes which led to very odd 
behavior. Is it possible that this is the cause?

Ali

Sent from my ARM powered device

On Feb 28, 2011, at 5:48 AM, Gabe Black  wrote:

> I ran into a problem a while back where the python and C++ versions of a
> simobject I was working with weren't meshing with each other, and M5 was
> segfaulting out and crashing. I worked around the problem and intended
> to mention this to the list, but I haven't gotten around to it until now.
> 
> Basically, the python version of the simobject had just one base, I
> believe, which wasn't very interesting. I think it may have simply been
> SimObject. On the C++ side, however, the object inherited from whatever
> SimObject was appropriate, but then also another class that had an
> interface and some functionality I wanted to have in my SimObject. When
> some infrastructure code tried to call init() on a new simobject of this
> type, what actually happened was that a destructor was called for one of
> the base classes. M5 then burst into flames died.
> 
> I think the issue is that the python wrapper stuff builds up a parallel
> object hierarchy that mirrors the python stuff which is supposed to
> mirror the C++ stuff. When manipulating pointers to the classes defined
> in regular C++, swig thinks it's manipulating pointers to it's parallel
> version of C++. That works fine when only single inheritance is used and
> pointers are always equal to each other (I think they are, at least),
> but that breaks down when multiple inheritance is being used. I think
> what happened was that the vtable pointer for the SimObject subobject
> was not at the lowest addresses of the inheriting subclass. When swig
> used a reinterpret_cast on the pointer it got back from the create
> function (that's what I remember it did, at least) it ended up referring
> to whatever vtable pointer actually was there, which I suppose was for
> either the other class or for the subclass itself. This meant that when
> it tried to call virtual function X which it expected to be init, it
> actually called function X in the wrong type of table which was really a
> destructor.
> 
> I spent a few minutes on a couple of occasions thinking about a way to
> handle all this that avoids this problem, but I didn't really think of
> anything. Things are generally they way they are because they need to be
> for one reason or another, and it's not apparent how to change things in
> a way that's not extremely obnoxious or destructive that covers this
> case as well. In any case, I thought it was important to mention I hit
> this issue even if I didn't have a way to fix it. I don't have the code
> around any more that was breaking, but I expect it wouldn't be that hard
> to reproduce.
> 
> Gabe
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
> 
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: SCons: Separately label the global non-sticky options.

[Gabe Black]

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

SCons: Separately label the global non-sticky options.

The global sticky options were being printed with a heading, and then the
global nonsticky options were being printed immediately after them without a
heading. Because the two lists ran together and the first had its own heading,
it looked like -all- those options where sticky even though some of them
aren't. This change adds a label to the second list so it's clear they're
different.


Diffs
-

  SConstruct c6ba129c2764 

Diff: http://reviews.m5sim.org/r/524/diff


Testing
---


Thanks,

Gabe

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

[m5-dev] Review Request: Ruby: Mention that Ruby's bound checking option only applies to Ruby.

[Gabe Black]

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

Ruby: Mention that Ruby's bound checking option only applies to Ruby.


Diffs
-

  src/mem/ruby/SConsopts c6ba129c2764 

Diff: http://reviews.m5sim.org/r/523/diff


Testing
---


Thanks,

Gabe

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

[m5-dev] Review Request: SCons: Clean up some inconsistent capitalization in scons options.

[Gabe Black]

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

SCons: Clean up some inconsistent capitalization in scons options.


Diffs
-

  SConstruct c6ba129c2764 
  src/mem/protocol/SConsopts c6ba129c2764 
  tests/SConscript c6ba129c2764 

Diff: http://reviews.m5sim.org/r/522/diff


Testing
---


Thanks,

Gabe

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

[m5-dev] GEMS_ROOT description text?

[Gabe Black]

I noticed just now that the GEMS_ROOT scons variable is described as
"Add debugging stuff to Ruby", but that doesn't make any sense since
it's value is apparently a directory. I suspect it's actual use is to
specify where in the M5 tree all the GEMS stuff is and that the
description is wrong. Since I'd never heard of GEMS_ROOT before now, at
least that I remember, I'll leave any actual changes to the Ruby experts.

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

[m5-dev] Multiple inheritance, sim objects, and swig

[Gabe Black]

I ran into a problem a while back where the python and C++ versions of a
simobject I was working with weren't meshing with each other, and M5 was
segfaulting out and crashing. I worked around the problem and intended
to mention this to the list, but I haven't gotten around to it until now.

Basically, the python version of the simobject had just one base, I
believe, which wasn't very interesting. I think it may have simply been
SimObject. On the C++ side, however, the object inherited from whatever
SimObject was appropriate, but then also another class that had an
interface and some functionality I wanted to have in my SimObject. When
some infrastructure code tried to call init() on a new simobject of this
type, what actually happened was that a destructor was called for one of
the base classes. M5 then burst into flames died.

I think the issue is that the python wrapper stuff builds up a parallel
object hierarchy that mirrors the python stuff which is supposed to
mirror the C++ stuff. When manipulating pointers to the classes defined
in regular C++, swig thinks it's manipulating pointers to it's parallel
version of C++. That works fine when only single inheritance is used and
pointers are always equal to each other (I think they are, at least),
but that breaks down when multiple inheritance is being used. I think
what happened was that the vtable pointer for the SimObject subobject
was not at the lowest addresses of the inheriting subclass. When swig
used a reinterpret_cast on the pointer it got back from the create
function (that's what I remember it did, at least) it ended up referring
to whatever vtable pointer actually was there, which I suppose was for
either the other class or for the subclass itself. This meant that when
it tried to call virtual function X which it expected to be init, it
actually called function X in the wrong type of table which was really a
destructor.

I spent a few minutes on a couple of occasions thinking about a way to
handle all this that avoids this problem, but I didn't really think of
anything. Things are generally they way they are because they need to be
for one reason or another, and it's not apparent how to change things in
a way that's not extremely obnoxious or destructive that covers this
case as well. In any case, I thought it was important to mention I hit
this issue even if I didn't have a way to fix it. I don't have the code
around any more that was breaking, but I expect it wouldn't be that hard
to reproduce.

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

Re: [m5-dev] Review Request: O3: Fix unaligned stores when cache blocked

[Timothy Jones]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/508/#review916
---

Ship it!


Looks good to me.  I didn't think about this case when originally writing the 
code.

- Timothy


On 2011-02-25 21:04:09, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/508/
> ---
> 
> (Updated 2011-02-25 21:04:09)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> O3: Fix unaligned stores when cache blocked
> 
> Without this change the a store can be issued to the cache multiple times.
> If this case occurs when the l1 cache is out of mshrs (and thus blocked)
> the processor will never make forward progress because each cycle it will
> send a single request using the recently freed mshr and not complete the
> multipart store. This will continue forever.
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/lsq_unit_impl.hh 9dc17725f795 
> 
> Diff: http://reviews.m5sim.org/r/508/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

[m5-dev] setting M5_PATH explicitly for the regressions

[Gabe Black]

Hi folks. I'm planning to try setting M5_PATH explicitly for the
regressions so it no longer depends on the default value. I'm going to
try setting it in the crontab file that fires off the regressions by
adding the following line after MAILTO.

M5_PATH="/n/poolfs/z/dist/m5/system"

I don't know for sure that that's right, but I'm fairly confident that
will do it. If I don't hear any dissenting opinions by this evening I'll
make the change, and we'll see whether it worked when the regressions
run tonight. I suppose we won't be able to tell for sure whether it was
the new value or the default that was used unless something breaks. That
makes it a win/win, right? :-)

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

[m5-dev] Cron /z/m5/regression/do-regression quick

[Cron Daemon]

* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory
 passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby 
passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* 
build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby 
passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed.
* build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed.
* build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed.
* 
build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp
 passed.
* 
build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp
 passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing 
passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic 
passed.
* 
build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp
 passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby 
passed.
* build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing passed.
* build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing-ruby 
passed.
* build/X8