This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: GSOC | Extending Common Lisp support
On 06/07/2012 06:55 AM, Charles Turner wrote:
Did you look here from experience with the code, or was it debugger
exploration? If so, what's you're standard entry point for bugs like
this? I tend to work from the syntax transformers, but I wonder if
there's a better place to start from.
I used --debug-dump-zip combined with a disassembler (in my case
I usually use gnu.bytecode.dump) to verify that the incorrect calls were
just reading the myfun static fields before calling the value found
there. Then I went back to the initial define, disassembled that,
and verified it's a final field. Thus since it had to be the same
ModuleMethod working and non-working, that means it's fields were being
changed.
I remembered doing the in-place modification to support re-binding,
but I wasn't sure how that was happening. Using "View Usages" in
NetBeans confirmed the selector and module fields were set in the
ModuleMethod#init method - and only here. A stack-trace in that
method (i.e. a "new Error("whatever").printStackTrace()") verified
that init was called during evaluation of the let, and in generated code.
The final issue was finding where the init was being generated in
the compiler. I added a stack trace in CodeAttr.emitInvoke, conditional
on the method having the name "init", which led to the problem area.
--
--Per Bothner
per@bothner.com http://per.bothner.com/