[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.
For
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
exceptions?
I'm kind of partial to cmucl's interface where you just list the
exceptions that you want to be signaled.
Camm> (:DIVISION-BY-ZERO)
>> (apply 'fdivp (list 1.0 0.0))
Camm> Condition in SYSTEM::GCL-TOP-LEVEL [or a callee]:
INTERNAL-SIMPLE-DIVISION-BY-ZERO:
Camm> Arithmetic error when performing (:INSN "fdivp %st,%st(1) ;" :OP
FDIVP
Camm> :FUN
Camm> #<compiled-function 0000000001006a60>
Camm> :ADDR 20714126) on (1.0 0.0):
Nice!
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
i386/x86_64.
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
from
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
easy.
The user can get the actual instruction by calling disassemble, right?
If so, there's no need to have the signal handler disassemble too.
Ray