On Thu, 21 Nov 2002, Leopold Toetsch wrote:
> > A bit more ... In particular, on Solaris, I've been able to track down
> > one way of triggering the the t/op/lexicals.t failure to list.c. If I
> > compile list.c without any optimization, the test passes. If I compile
> > just the list_new function in list.c with the lowest optimization (-xO1,
> > defined in the man page as "Does basic local optimization (peephole)"),
> > those tests fail.
>
> Thanks for tracking it down that far.
> Does this patch help:
>
> --- dod.c Wed Nov 6 11:19:32 2002
> +++ /home/lt/src/parrot-leo/dod.c Thu Nov 21 08:29:08 2002
> @@ -66,6 +66,14 @@
> struct Stash *stash;
> UINTVAL mask = PMC_is_PMC_ptr_FLAG | PMC_is_buffer_ptr_FLAG
> | PMC_custom_mark_FLAG;
> +#ifdef HAS_HEADER_SETJMP
> + jmp_buf env;
> +
> + /* this should put registers in env, which then get marked in
> + * trace_system_stack below
> + */
> + setjmp(env);
> +#endif
Alas, no, though it seems to me you may be on the right track. What
appears to be happening is that sub.c is getting lex->names from list_new,
but (when compiled with optimization) list_new is returning a list that is
not on the stack. Indeed, if I try to use the debugger and "print list"
while in list_new, I simply get
(dbx) print list
list = (nil)
The smallest change I have found to make it work is to add the single
line fiddle(&list) to the end of list_new (where fiddle is a do-nothing
function hidden away in another file so that the compiler can't
optimize it away). This, however, adds the requirement that the
compiler put list somewhere where it can validly take its address, and
t/op/lexicals_1.pbc works again. (I haven't checked yet whether all
the other tests also succeed. I suspect not, however since I think you
are right that the stack-walking is the problem. list.c:list_new looks
fine -- it just happens to be the first file I found where the
optimizer made a difference.
--
Andy Dougherty [EMAIL PROTECTED]
