[squeak-dev] Re: Debbuging problems, FFI
Andreas Raab
andreas.raab at gmx.de
Sun Aug 2 18:06:50 UTC 2009
Mariano Martinez Peck wrote:
> Javier has done an excellent job and here is his last post. Can someone
> read what he found and see if we can fix this annoying bug?
The problem is that you can't call #valueWithReceiver:args: since this
would both execute the entire method and do it in the wrong context
where instead you need to execute *just* the primitive (since you'll
simulate the rest if it fails).
Fortunately, external functions have two ways to invoke them; one
implicitly as primitive in a method (i.e., prim 120) and another one
explicitly (via invokeWithArgs:). A variant on the latter that returns
ContextPart>>primFailToken does the trick nicely.
I've updated both http://source.squeak.org/FFI and
http://source.squeak.org/trunk with the ncessary bits.
Cheers,
- Andreas
>
> Thanks,
>
> Mariano
>
>
> ---------- Forwarded message ----------
> From: *Javier Pimás* <elpochodelagente at gmail.com
> <mailto:elpochodelagente at gmail.com>>
> Date: 2009/8/2
> Subject: Re: [Pharo-project] Debbuging problems, FFI
> To: Pharo-project at lists.gforge.inria.fr
> <mailto:Pharo-project at 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 at gmail.com
> <mailto:marianopeck at gmail.com>>
>
>
>
> 2009/7/31 Javier Pimás <elpochodelagente at gmail.com
> <mailto:elpochodelagente at 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 at gmail.com <mailto:elpochodelagente at 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 at gmail.com
> <mailto:marianopeck at 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 at gmail.com
> <mailto:elpochodelagente at 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 at lists.gforge.inria.fr
> <mailto:Pharo-project at lists.gforge.inria.fr>
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> <mailto:Pharo-project at 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 at lists.gforge.inria.fr
> <mailto:Pharo-project at lists.gforge.inria.fr>
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> <mailto:Pharo-project at 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 at lists.gforge.inria.fr
> <mailto:Pharo-project at lists.gforge.inria.fr>
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ------------------------------------------------------------------------
>
>
More information about the Squeak-dev
mailing list
|