Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> t/pmc/io_2 is failing on some tinderboxen that don't have memalign and
> therefore don't have ARENA_DOD_FLAGS set. Besides the wrong count of DOD
> runs, the primary problem is:
> The ParrotIO object is found to be alive in some system areas (probably
> processor registers). Due to the conservative approach of the DOD
> strategy this always might happen.
> I think, we have a problem.
I have a (partial?) solution for this. What AFAIK is going on is
something like this:
C-stack: Parrot_open() ... later ... do_dod_run()
... ...
$1 = pmc_new sub $0x44, %esp
...
IO-PMC ----------------------->
...
trace_system_stack()
So during a DOD run the trails of an IO PMC are found on the system
stack during trace_mem_block. The main problem seems to be, that gcc
uses 16-byte aligned stack frames by default. So there are "holes" in
the stack, where it is not unlikely, that we find trails of PMCs used
in earlier functions calls.
I did compile parrot with:
-mpreferred-stack-boundary=2
and the t/pmc/io_2.pasm test succeeds with all run loops then.
As we don't pass around mmx/sse memory locations above option should be
safe.
For i386 JIT/CGP we need another options for gcc 3.x (with some x)
(s. "[perl #22353] JIT!")
-mno-accumulate-outgoing-args
But I don't know, in which config file these should go.
leo
