Re: Handling 'external' trap events

[Mark Wielaard <mark at klomp dot org>]

Hi Yao,

On Wed, 2006-10-11 at 11:15 +0800, Yao Qi wrote:
> Now, both "int 3" on x86 and ".long 0x7d821008" on ppc64 could
> generate a SIGTRAP, but with the *different* side-effect.  "int 3",
> which is a valid instruction, cause a SIGTRAP and program counter
> increment, but ".long 0x7d821008", which is an *invalid*
> instruction, cause a SIGTRAP but *no* update to program counter.

Aha. I didn't realize that.

> (The following part is my guesswork.  If I am wrong, free to correct
> me)
> when frysk core get a SIGTRAP, could not find observers installed
> on the specified address, frysk core will resume the program from the
> unfinished instruction(on powerpc), which is still an invalid 
> instruction.  So a endless loop is made.

If no observers are installed on the specified address then we make the
program handle the sigtrap. See TaskState.Running.handleTrapEvent():

        int blockers = task.notifyCodeBreakpoint(address);
        if (blockers == -1)
          {
            // This is not a trap event generated by us.
            return handleSignaledEvent (task, Sig.TRAP_);
          }

And in this case the funit-breakpoints.c (trap_handler) does nothing
fancy and just returns. Which on a x86 means after the instruction that
trapped, but as you found out on powerpc means at the same trapping
instruction.

> I could not figure out how to ask cpu to skip this invalid
> instruction to avoid endless loop after hit it for the first time.
> So I comment out that inlined asm as a workaround in this patch.
> 
> 2006-10-11  Yao Qi  <qiyaoltc@cn.ibm.com>
> 
>         * funit-breakpoints.c (dummy): Remove inline asm that generate
>         SIGTRAP for powerpc.
>         (main): Change the condition according to the change above.
> 
> OK to commit?  Thanks!

It think this is the wrong thing to do. We should really skip the
illegal instruction from the trap handler in funit-breakpoints.c. What
we are after is using breakpoints with a program that handles its own
sig trap events. Maybe a good way to simulate this is using setjmp and
longjmp to return from the trap signal handler. That should be platform
independent.

Cheers,

Mark