> Cheers,
> - Andreas
>
>>
>> Thanks,
>>
>> Mariano
>>
>>
>> ---------- Forwarded message ----------
>> From: *Javier Pimás* <
elpochodelagente@gmail.com
>> <mailto:
elpochodelagente@gmail.com>>
>> Date: 2009/8/2
>> Subject: Re: [Pharo-project] Debbuging problems, FFI
>> To:
Pharo-project@lists.gforge.inria.fr
>> <mailto:
Pharo-project@lists.gforge.inria.fr>
>>
>>
>> I Think I found where the problem lies, it's just sitting there waiting to
>> be resolved.
>>
>> To see what was happening I debugged the debuger, which was really weird.
>> I found the answer when I broke into the step over button by adding a self
>> break in OTCmdOverDebugger>>execute. After catching it I removed the break
>> and stepped into everything to see how step over worked. The intresting part
>> is in MethodContext(ContextPart)>>step, which sends
>> interpretNextInstructionFor: self. The idea is this, instead of advancing
>> the vm program counter within the vm code, the debugger simulates the
>> execution cycle, step by step. It not so hard as it seems but also not very
>> simple. The problem comes when the debugger tryies to simulate primitive
>> calls. When the simulator detects a primitive, it issues a
>> MethodContext(ContextPart)>>doPrimitive:method:receiver:args:, here you can
>> see the detection:
>>
>> tryPrimitiveFor: method receiver: receiver args: arguments
>> "..."
>> | primIndex |
>> (primIndex := method primitive) = 0 ifTrue: [^ PrimitiveFailToken].
>> ^ self doPrimitive: primIndex method: method receiver: receiver args:
>> arguments
>>
>> well, the problem is that doPrimitive doesn't seem to implement all
>> primitives (I recomend you to look it's code), but just a few ones. Also, as
>> far as I can see, it calls primitive 19, which i found is (by looking vm C
>> code) primitiveFail, and that primitive just sets a flag that says that
>> something failed.
>>
>> Then, if my calculations are correct, the problem is that the FFI Call
>> primitive needs to be handled by hand. I tryied adding this to
>> ContextPart>>doPrimitive:method:receiver:args:
>>
>> primitiveIndex = 120 ifTrue: "Calling an FFI method, just evaluate it and
>> return"
>> [ meth valueWithReceiver: receiver arguments: arguments . ^self].
>>
>> just before
>>
>> arguments size > 6 ifTrue: [^PrimitiveFailToken].
>>
>> which I think almost worked. I think the primitive was executed, but this
>> doesn't handle the execution context that is being simulated, and the stack
>> gets corrupted. Somebody with more experience in ContextPart, MethodContext,
>> etc. may give us a hand here, I think the fix is almost there.
>>
>> Bye,
>> Javier.
>>
>> 2009/7/31 Mariano Martinez Peck <
marianopeck@gmail.com
>> <mailto:
marianopeck@gmail.com>>
>>
>>
>>
>> 2009/7/31 Javier Pimás <
elpochodelagente@gmail.com
>> <mailto:
elpochodelagente@gmail.com>>
>>
>> Does anybody know if the problem occurs just in Windows or in
>> any OS? this can give a clue of the problem...
>>
>>
>> I don't remember debugging in Windows, but in Linux I have this
>> problem for sure.
>>
>>
>> On Thu, Jul 30, 2009 at 11:28 PM, Javier Pimás
>> <
elpochodelagente@gmail.com <mailto:
elpochodelagente@gmail.com>>
>> wrote:
>>
>> Well, at least I feel better that I'm not crazy, (or not the
>> only one...). Maybe if someone could give us a clue about
>> it, we could spot where the problem is. Do you think it is a
>> vm problem or something related to the smalltalk code?
>>
>> 2009/7/30 Mariano Martinez Peck <
marianopeck@gmail.com
>> <mailto:
marianopeck@gmail.com>>
>>
>> Yes. This is really annoying for me. I am writing a C
>> library plugin since a year and a half and this is very
>> frustrated :(
>> You cannot debug when using FFI. I mean, you cannot get
>> advantages of one of the best Smalltalk features! What I
>> do is to write a self break before and after the call
>> and use "proceed" but I don't like it at all.
>>
>> Once I tried to see what the problem was, but I was to
>> difficult to me to understand it and fix it. We need a
>> guru here I think hahaha.
>>
>> Best,
>>
>> Mariano
>>
>> 2009/7/30 Javier Pimás <
elpochodelagente@gmail.com
>> <mailto:
elpochodelagente@gmail.com>>
>>
>> Hi, I'm having problems with the debugger. Every
>> time I try to debug code that uses FFI, if I step
>> over a message that internally does an FFI call, I
>> get an externalCallFailed error and then I land in
>> MethodContext(ContextPart)>>runUntilErrorOrReturnFrom:
>> If I run the code without debugging, then I have no
>> problems at all.
>>
>> I'm using SqueakPharo v3.11.2 with
>> pharo0.1-10373web09.07.2.
>>
>> To reproduce it you can try this:
>>
>> ScriptLoader loadFFI.
>> then load latest GLMorphic from squeaksource, and
>> uncomment the "self break." in
>> GLCanvas>>displayString:from:to:at:strikeFont:kern:
>>
>> doit
>> World fullDrawOn: GLDisplayScreen testCanvas
>> hit debug and step over until you reach
>> ogl glTexImage2D: GLTexture2d with:...
>>
>> also you'll see wrong values for local vars, like
>> aPoint which will look as #(nil nil nil nil nil)
>> when it'll actually have a point.
>>
>> Is there any other way to set up a break point
>> instead of adding self break to the code??
>>
>> Thanks,
>> Javier.
>>
>> -- Javier Pimás
>> Ciudad de Buenos Aires
>>
>> _______________________________________________
>> Pharo-project mailing list
>>
Pharo-project@lists.gforge.inria.fr
>> <mailto:
Pharo-project@lists.gforge.inria.fr>
>>
>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>>
Pharo-project@lists.gforge.inria.fr
>> <mailto:
Pharo-project@lists.gforge.inria.fr>
>>
>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>>
>> -- Javier Pimás
>> Ciudad de Buenos Aires
>>
>>
>>
>>
>> -- Javier Pimás
>> Ciudad de Buenos Aires
>>
>> _______________________________________________
>> Pharo-project mailing list
>>
Pharo-project@lists.gforge.inria.fr
>> <mailto:
Pharo-project@lists.gforge.inria.fr>
>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>>
Pharo-project@lists.gforge.inria.fr
>> <mailto:
Pharo-project@lists.gforge.inria.fr>
>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>>
>> --
>> Javier Pimás
>> Ciudad de Buenos Aires
>>
>> _______________________________________________
>> Pharo-project mailing list
>>
Pharo-project@lists.gforge.inria.fr
>> <mailto:
Pharo-project@lists.gforge.inria.fr>
>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>
>
>