jyapayne/swig
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

*** empty log message ***

Browse source 
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@1074 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Dave Beazley 2001-04-02 22:30:07 +00:00
commit 1cec62c1a7
1 changed files with 19 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

33
Tools/WAD/Papers/usenix2001.tex
View file

@ -136,7 +136,7 @@ Because of this, scripted software tends to rely heavily
upon shared libraries, dynamic loading, scripts, and upon shared libraries, dynamic loading, scripts, and
third-party extensions. In this sense, one might argue that the third-party extensions. In this sense, one might argue that the
benefits of scripting are achieved at the expense of creating a benefits of scripting are achieved at the expense of creating a
more complicated and decentralized development environment. more complicated and diverse development environment.
A consequence of this complexity is an increased degree of difficulty A consequence of this complexity is an increased degree of difficulty
associated with debugging programs that utilize multiple languages, associated with debugging programs that utilize multiple languages,
@ -190,7 +190,7 @@ that the only way for a user to narrow the source of the problem
within a script is through trial-and-error techniques such as within a script is through trial-and-error techniques such as
inserting print statements, commenting out sections of scripts, or inserting print statements, commenting out sections of scripts, or
having a deep intuition of the underlying implementation. Obviously, having a deep intuition of the underlying implementation. Obviously,
none of these techniques are particularly satisfactory. none of these techniques are particularly elegant.
An alternative approach is to run the application under the control of An alternative approach is to run the application under the control of
a traditional debugger such as gdb \cite{gdb}. Although this provides a traditional debugger such as gdb \cite{gdb}. Although this provides
@ -219,7 +219,7 @@ better integration with scripting languages, it is not clear that this
would be the most natural solution to the problem. For one, would be the most natural solution to the problem. For one,
having to run a separate debugging process to debug having to run a separate debugging process to debug
extension code is unnatural when no such requirement exists for extension code is unnatural when no such requirement exists for
scripts. Furthermore, even if such a debugger existed, an scripts. Moreover, even if such a debugger existed, an
inexperienced user may not have the expertise or inclination to use inexperienced user may not have the expertise or inclination to use
it. Finally, obscure fatal errors may occur long after an application it. Finally, obscure fatal errors may occur long after an application
has been deployed. Unless the debugger is distributed along with the has been deployed. Unless the debugger is distributed along with the
@ -381,7 +381,7 @@ detailed error information is first registered with the interpreter
and then a special error code is returned. For example, in Tcl, errors and then a special error code is returned. For example, in Tcl, errors
are handled by setting error information in the interpreter and are handled by setting error information in the interpreter and
returning a value of TCL\_ERROR. Similarly in Python, errors are returning a value of TCL\_ERROR. Similarly in Python, errors are
handled by raising an exception and returning NULL. In both cases, handled by calling a special function to raise an exception and returning NULL. In both cases,
this triggers the interpreter's error handler---possibly resulting in this triggers the interpreter's error handler---possibly resulting in
a stack trace of the running script. In some cases, an interpreter a stack trace of the running script. In some cases, an interpreter
might handle errors using a form of the C {\tt longjmp} function. might handle errors using a form of the C {\tt longjmp} function.
@ -409,11 +409,11 @@ produce signals that cause the interpreter to crash.
Most scripting languages provide limited support for Unix signal Most scripting languages provide limited support for Unix signal
handling \cite{stevens}. However, this support is not sufficiently advanced to handling \cite{stevens}. However, this support is not sufficiently advanced to
recover from fatal signals produced by extension code. recover from fatal signals produced by extension code.
First, unlike signals generated for asynchronous events such as I/O, Unlike signals generated for asynchronous events such as I/O,
execution can {\em not} be resumed at the point of a fatal signal. execution can {\em not} be resumed at the point of a fatal signal.
Therefore, even if such a signal could be caught and handled by a script, Therefore, even if such a signal could be caught and handled by a script,
there isn't much that it can do except to print a diagnostic there isn't much that it can do except to print a diagnostic
message and abort before the signal handler returns. Second, message and abort before the signal handler returns. In addition,
some interpreters block signal delivery while executing some interpreters block signal delivery while executing
extension code--opting to handle signals at a time when it is more convenient. extension code--opting to handle signals at a time when it is more convenient.
In this case, a signal such as SIGSEGV would simply cause the whole application In this case, a signal such as SIGSEGV would simply cause the whole application
@ -428,7 +428,7 @@ and SIGFPE using the {\tt sigaction} function
\cite{stevens}. Furthermore, it uses a special option (SA\_SIGINFO) of \cite{stevens}. Furthermore, it uses a special option (SA\_SIGINFO) of
signal handling that passes process context information to the signal signal handling that passes process context information to the signal
handler when a signal occurs. Since none of these signals are normally used in the handler when a signal occurs. Since none of these signals are normally used in the
implementation of the scripting interpreter or by any user scripts, implementation of the scripting interpreter or by user scripts,
this does not usually override any previous signal handling. this does not usually override any previous signal handling.
Afterwards, when one of these signals occurs, a two-phase recovery Afterwards, when one of these signals occurs, a two-phase recovery
process executes. First, information is collected about the execution process executes. First, information is collected about the execution
@ -622,7 +622,7 @@ In this case, the Tcl interpreter argument passed to a wrapper function
is stolen and used to generate an error. Also, the name {\tt TclExecuteByteCode} is stolen and used to generate an error. Also, the name {\tt TclExecuteByteCode}
refers to the calling function, not the wrapper function itself. refers to the calling function, not the wrapper function itself.
At this time, argument stealing is only applicable to simple types At this time, argument stealing is only applicable to simple types
such as integers and pointers. However, this is adequate for generating such as integers and pointers. However, this appears to be adequate for generating
scripting language errors. scripting language errors.
\section{Register Management} \section{Register Management}
@ -710,12 +710,11 @@ As a fall-back, WAD could be configured to return control to a location
previously specified with {\tt setjmp}. Unfortunately, this either previously specified with {\tt setjmp}. Unfortunately, this either
requires modifications to the interpreter or its extension modules. requires modifications to the interpreter or its extension modules.
Although this kind of instrumentation could be facilitated by automatic Although this kind of instrumentation could be facilitated by automatic
wrapper code generators, it is not a preferred solution and is wrapper code generators, it is not a preferred solution.
not discussed further.
\section{Initialization} \section{Initialization}
To simplify the debugging of extension module, it To simplify the debugging of extension modules, it
is desirable to make the use of WAD as transparent as possible. is desirable to make the use of WAD as transparent as possible.
Currently, there are two ways in which the system is used. First, WAD Currently, there are two ways in which the system is used. First, WAD
may be explicitly loaded as a scripting language extension module. may be explicitly loaded as a scripting language extension module.
@ -725,7 +724,7 @@ enabled by linking it to an extension module as a shared
library. For instance: library. For instance:
\begin{verbatim} \begin{verbatim}
% ld -shared $(OBJS) -o module.so -lwadpy % ld -shared ... -lwadpy
\end{verbatim} \end{verbatim}
In this case, WAD initializes itself whenever the extension module is In this case, WAD initializes itself whenever the extension module is
@ -755,11 +754,14 @@ simply by linking or loading; no special initialization code needs to
be added to an extension module to make it work. In addition, due to be added to an extension module to make it work. In addition, due to
the way in which the loader resolves and initializes libraries, the the way in which the loader resolves and initializes libraries, the
initialization of WAD is guaranteed to execute before any of the code initialization of WAD is guaranteed to execute before any of the code
in the extension module to which it has been linked executes. The primary in the extension module to which it has been linked. The primary
downside to this approach is that WAD shared object file can not be downside to this approach is that WAD shared object file can not be
linked directly to an interpreter (since its initialization would linked directly to an interpreter (since its initialization would
occur before any code in the interpreter started and the occur before any code in the interpreter started and the
initialization of WAD may require the interpreter to be active). initialization of WAD may require the interpreter to be active).
However, such limitations would be easy to fix by simply relinking
WAD without the C++ initializer and placing an initialization call
within the interpreter startup code.
\section{Exception Objects} \section{Exception Objects}
@ -963,7 +965,10 @@ Due to the heavy dependence on Unix signal handling, process
introspection, and object file formats, it is unlikely that WAD could introspection, and object file formats, it is unlikely that WAD could
be easily ported to non-Unix systems such as Windows. However, it may be easily ported to non-Unix systems such as Windows. However, it may
be possible to provide a similar capability using advanced features of be possible to provide a similar capability using advanced features of
structured exception handling \cite{seh}. structured exception handling \cite{seh}. For instance, structured
exception handlers can be used to catch hardware faults, they can
receive process context information, and they can arrange to take
corrective action.
\section{Modification of Interpreters?} \section{Modification of Interpreters?}