[m5-dev] shadow parameter definitions
I just figured out a rather annoying bug in the CPU where the profile event got scheduled at a totally bogus time which killed the simulation. The problem is that there's a profile parameter in both the atomic simple CPU and the base CPU. The atomic simple CPU sets it's version of profile at some point but the base CPU one never does. I'm guessing that's because the atomic CPU's definition masks the other when the parameter values get loaded up. Then, in the C++, if you refer to the profile member variable of the params struct, the hidden version is in scope that never got populated. There's several different things I can see as the right thing to do in this situation, but I'm sure what it's doing right now isn't it. First, we could say this sort of thing (params overwriting each other) is illegal, and we throw an error when it happens. This seems the most reasonable since you'd probably have a hard time even setting the hidden version in python. The other version, which at least would prevent wild dangling values, would be to initialize both versions of the parameter according to their defaults. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] shadow parameter definitions
There's several different things I can see as the right thing to do in this situation, but I'm sure what it's doing right now isn't it. First, we could say this sort of thing (params overwriting each other) is illegal, and we throw an error when it happens. This seems the most reasonable since you'd probably have a hard time even setting the hidden version in python. The other version, which at least would prevent wild dangling values, would be to initialize both versions of the parameter according to their defaults. Rick Strong just found this bug last week, and he just committed a fix for it. I agree that we need to catch this, and I'm personally in favor of raising an exception in the case where one value shadows another. The other option (initialize all values) would be much more difficult and doesn't seem worth it. Can you add a flyspray task and assign it to me? Thanks, Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] shadow parameter definitions
nathan binkert wrote: There's several different things I can see as the right thing to do in this situation, but I'm sure what it's doing right now isn't it. First, we could say this sort of thing (params overwriting each other) is illegal, and we throw an error when it happens. This seems the most reasonable since you'd probably have a hard time even setting the hidden version in python. The other version, which at least would prevent wild dangling values, would be to initialize both versions of the parameter according to their defaults. Rick Strong just found this bug last week, and he just committed a fix for it. I agree that we need to catch this, and I'm personally in favor of raising an exception in the case where one value shadows another. The other option (initialize all values) would be much more difficult and doesn't seem worth it. Can you add a flyspray task and assign it to me? Thanks, Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev I must have missed that commit email, but I pulled the change and profile seems to be fixed. function_trace and function_trace_start have the same problem and weren't changed so I'll push a fix for that if nobody minds. The flyspray task is added. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
