Checking type safety of foreign function calls

Foster, Jeffrey S.

doi:10.1145/1377492.1377493

Cited by 21 publications

(1 citation statement)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Previous work proposed preliminary formalisms that capture certain aspects of the JNI. Furr and Foster justified J-Saffire's soundness on a formalization of a subset of the JNI (Furr and Foster 2008). It models only the native side, and treats Java objects opaquely.…”

Section: Related Workmentioning

confidence: 99%

JNI light: an operational model for the core JNI

Tan¹

2014

Math. Struct. Comp. Sci.

View full text Add to dashboard Cite

Abstract. Through foreign function interfaces (FFIs), software components in different programming languages interact with each other in the same address space. Recent years have witnessed a number of systems that analyze FFIs for safety and reliability. However, lack of formal specifications of FFIs hampers progress in this endeavor. We present a formal operational model, JNI Light (JNIL), for a subset of a widely used FFI-the Java Native Interface (JNI). JNIL focuses on the core issues when a high-level garbage-collected language interacts with a low-level language. It proposes abstractions for handling a shared heap, crosslanguage method calls, cross-language exception handling, and garbage collection. JNIL can directly serve as a formal basis for JNI tools and systems. The abstractions in JNIL are also useful when modeling other FFIs, such as the Python/C interface and the OCaml/C interface. MotivationMost modern programming languages support foreign function interfaces (FFIs) for interoperating with program modules developed in other programming languages. Recent years have witnessed a string of systems that analyze and improve FFIs for safety and reliability [1,2,3,4,5,6,7,8]. However, lack of formal semantics of FFIs hampers progress in this domain. The available specifications of FFIs are in prose. Relying on prose specifications has at least two unpleasant consequences. First, prose specifications are often ambiguous and sometimes incomplete. The situation is especially acute for an FFI, whose two sides involve different programming models and language features. For instance, Lee et al. reported that Sun's HotSpot and IBM's J9 behave differently for four out of ten JNI test cases [8, Table 1]. In such situations, the best an FFI user can do is to perform experiments on particular implementations and make an educated guess. This may cause inconsistencies and unsoundness. Second, without formal semantics, tools and analyzers cannot provide rigorous claims about their strength. As a result, previous systems that target FFIs have to argue their hypotheses and claims informally. This leaves their strength in doubt.While there have been many efforts in formalizing the semantics of programming languages, almost all have ignored the FFI aspect. The work by Matthews and Findler [9] formalizes the interoperation between two high-level functional languages, one typed and the other untyped. While this formalism represents significant progress in modeling language interoperation, it does not apply to FFIs. Most FFIs are about the interaction in the shared memory between a high-level language and a low-level language (assembly languages, C, and C++).This paper presents the first formal operational model, named JNI Light (JNIL), for a subset of a shared-memory foreign function interface-the JNI interface. The major challenge for the modeling effort is to have the right abstractions to accommodate differences between the programming models of Java and native code, without unduly complicating the model. This is challe...

show abstract

Section: Related Workmentioning

confidence: 99%

JNI light: an operational model for the core JNI

Tan¹

2014

Math. Struct. Comp. Sci.

View full text Add to dashboard Cite

show abstract

Debugging mixed-environment programs with Blink

Lee

Hirzel

Grimm

et al. 2014

Softw. Pract. Exper.

View full text Add to dashboard Cite

Programmers build large-scale systems with multiple languages to leverage legacy code and languages best suited to their problems. For instance, the same program may use Java for ease of programming and C to interface with the operating system. These programs pose significant debugging challenges, because programmers need to understand and control code across languages, which often execute in different environments. Unfortunately, traditional multilingual debuggers require a single execution environment. This paper presents a novel composition approach to building portable mixed-environment debuggers, in which an intermediate agent interposes on language transitions, controlling and reusing single-environment debuggers. We implement debugger composition in Blink, a debugger for Java, C, and the Jeannie programming language. We show that Blink is (i) simple: it requires modest amounts of new code; (ii) portable: it supports multiple Java virtual machines, C compilers, operating systems, and component debuggers; and (iii) powerful: composition eases debugging, while supporting new mixed-language expression evaluation and Java native interface bug diagnostics. To demonstrate the generality of interposition, we build prototypes and demonstrate debugger language transitions with C for five of six other languages (Caml, Common Lisp, C#, Perl 5, Python, and Ruby) without modifications to their debuggers. Using real-world case studies, we show that diagnosing language interface errors require prior single-environment debuggers to restart execution multiple times, whereas Blink directly diagnoses them with one execution.Traditional debuggers are not much help with mixed-language programs because they are limited to a single execution environment. For example, native programs and their debuggers (e.g., the gdb debugger for C, C++, and Fortran) require language implementations to use the same application binary interface (ABI). The ABI is machine dependent and thus precludes portable execution environments for managed languages, such as Java, C#, JavaScript, and Python. For portability, managed languages rely on virtual machine (VM) execution, using interpretation, just-in-time compilation, and garbage collection. They abstract over internal code, the stack, and data representations. Debuggers for managed languages, such as the standard Java debugger jdb, operate on VM abstractions, for example, through the Java Debug Wire Protocol (JDWP), but do not understand native code. Current mixed-language debuggers are limited to XDI and dbx, which support Java and C within a single JVM [6,7], and the Visual Studio debugger, which supports managed and native code in the Common Language Runtime (CLR) [8]. While these debuggers understand all environments, they are behemoths that are generally not portable. The challenge when building a mixed-environment debugger is that each environment has different representations; managed debuggers operate at the level of bytecodes and objects, whereas native debuggers deal with machine instructio...

show abstract

A Multilanguage Static Analysis of Python Programs with Native C Extensions

Monat

Ouadjaout

Miné

2021

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Modern programs are increasingly multilanguage, to benefit from each programming language's advantages and to reuse libraries. For example, developers may want to combine high-level Python code with low-level, performance-oriented C code. In fact, one in five of the 200 most downloaded Python libraries available on GitHub contains C code. Static analyzers tend to focus on a single language and may use stubs to model the behavior of foreign function calls. However, stubs are costly to implement and undermine the soundness of analyzers. In this work, we design a static analyzer by abstract interpretation that can handle Python programs calling C extensions. It analyses directly and fully automatically both the Python and the C source codes. It reports runtime errors that may happen in Python, in C, and at the interface. We implemented our analysis in a modular fashion: it reuses off-the-shelf C and Python analyses written in the same analyzer. This approach allows sharing between abstract domains of different languages. Our analyzer can tackle tests of real-world libraries a few thousand lines of C and Python long in a few minutes.

show abstract

Checking type safety of foreign function calls

Cited by 21 publications

References 29 publications

JNI light: an operational model for the core JNI

JNI light: an operational model for the core JNI

Debugging mixed-environment programs with Blink

A Multilanguage Static Analysis of Python Programs with Native C Extensions

Contact Info

Product

Resources

About