[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] libopcodes

From: Raymond Toy
Subject: Re: [Gcl-devel] libopcodes
Date: Thu, 08 May 2014 09:35:10 -0700
User-agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b34 (linux)

>>>>> "Camm" == Camm Maguire <address@hidden> writes:

    Camm> Greetings!  I am considering releaseing a SIGFPE handler in 2.6.11.  
    Camm> example, here is how it works:

    >> (si::break-on-floating-point-exceptions :division-by-zero t)

Presumably there are other keyword args for the other possible

I'm kind of partial to cmucl's interface where you just list the
exceptions that you want to be signaled.


    >> (apply 'fdivp (list 1.0 0.0))

    Camm> Condition in SYSTEM::GCL-TOP-LEVEL [or a callee]: 
    Camm> Arithmetic error when performing (:INSN "fdivp  %st,%st(1) ;" :OP 
    Camm> :FUN
    Camm> #<compiled-function 0000000001006a60>
    Camm> :ADDR 20714126) on (1.0 0.0): 


    Camm> GCL is supporting all linux, bsd, macosx 10.8, mingw and cygwin these
    Camm> days.  Solaris is in the works.  All non-linux targets are 
    Camm> I looked into disassembling the instruction directly, but this is
    Camm> extremely fragile and error prone.  What's more, our #'disassemble
    Camm> function will already call binutils objdump for the most useful output
    Camm> if present.  So I'm looking for some suggestions here, all the way 
    Camm> "No one cares about the disassembly" to "Depend on binutils across the
    Camm> board, as it can easily be made available everywhere."

I don't think disassembly is that important. It's rather nice, but the
important part is that you can catch them.  It's a bonus to know the
operation and the arguments.  What cmucl does is just look at
instruction at the offending address, figure out what the operation was
and get the operands when possible.  But we only do this on x86 for
sse2 instructions and only if the arg is in a register, to make it

The user can get the actual instruction by calling disassemble, right?
If so, there's no need to have the signal handler disassemble too.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]