gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] libopcodes


From: Camm Maguire
Subject: [Gcl-devel] libopcodes
Date: Wed, 07 May 2014 15:15:26 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

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

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

(:DIVISION-BY-ZERO)

>(apply 'fdivp (list 1.0 0.0))

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

Fast links are on: do (use-fast-links nil) for debugging
Broken at APPLY.  Type :H for Help.
 1 (Abort) Return to top level.
dbl:>>1

Top level.
>(si::break-on-floating-point-exceptions)

(:DIVISION-BY-ZERO)

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

NIL

>(setq si::*print-nans* t)

T

>(apply 'fdivp (list 1.0 0.0))

#<inf>

>


I'm using libopcodes to disassemble the instruction, and then read the
registers and look them up in the sigcontext to get the operands.

My question is portability.  While gcl requires a C compiler at runtime,
it does not explicitly require binutils, though gcc will bring it in.
All linux, bsd, cygwin will work, but macosx and mingw will just throw
the FPE error code and address, unless I do as gdb does and build my own
local copy of libopcodes.  I hesitate to do this, as this will make gcl
GPL instead of LGPL, and also partially revert the earlier work I've
done eliminating bintuils from the source.  Right now I detect the
library at configure time and chop the output if absent.

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

Take care,
-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

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