It was in a set of microops I made which just panic/warn/etc with a string you
pass as the argument. It lets you use that sort of functionality at the
microcode level of abstraction which is fairly handy. Anyway, the string was
just a regular English sentence with a ".", a "(" and a ")" if I remember
correctly. I can't dig into the code at the moment so this might not be quite
right, but if you go into arch/x86/isa/insts/general_purpose/logical.py, go to
the microcode for XOR_R_R which is the first macroop executed in SE in the
regressions, and add

warn "This is an example warning"

to the beginning of that block, you should be able to very quickly reproduce the
problem with any of the regressions.

Gabe

Quoting nathan binkert <[EMAIL PROTECTED]>:

> You mean a std::string? I guess I could disallow std::string as the
> format string and only allow const char *.  This probably isn't overly
> burdensome.  Though the question is, what was in the string that
> caused it to break?  In theory, it should work, unless there are a lot
> of %s in it.  And I could probably fail those a bit more gracefully.
>
>   Nate
>
> On Thu, Oct 2, 2008 at 12:49 AM, Gabe Black <[EMAIL PROTECTED]> wrote:
> >    I just fixed a nasty memory bug where I was unwittingly passing a
> > string as the format argument of warn. I believe what happened was that
> > it was treating the string as a character pointer directly, and that
> > somehow broke the stack (or not? I'm not sure) and forced __warn to
> > recurse until the stack ran out and everything exploded. The segfault
> > could also have just been from the stack running out. It was hard to
> > tell what happened. In any case, it's something people should avoid
> > doing. Is there some way to handle this correctly, or at least complain
> > about a type mismatch or something and not self destruct?
> >
> > 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

Reply via email to