SPLLIFT — Statically Analyzing Software Product Lines in Minutes Instead of Years Eric Bodden1 Tarsis´ Toledoˆ 3 Marcio´ Ribeiro3;4 Claus Brabrand2 Paulo Borba3 Mira Mezini1 1 EC SPRIDE, Technische Universitat¨ Darmstadt, Darmstadt, Germany 2 IT University of Copenhagen, Copenhagen, Denmark 3 Federal University of Pernambuco, Recife, Brazil 4 Federal University of Alagoas, Maceio,´ Brazil [email protected], ftwt, [email protected], [email protected], [email protected], [email protected] Abstract A software product line (SPL) encodes a potentially large variety v o i d main () { of software products as variants of some common code base. Up i n t x = secret(); i n t y = 0; until now, re-using traditional static analyses for SPLs was virtu- # i f d e f F ally intractable, as it required programmers to generate and analyze x = 0; all products individually. In this work, however, we show how an # e n d i f important class of existing inter-procedural static analyses can be # i f d e f G transparently lifted to SPLs. Without requiring programmers to y = foo (x); LIFT # e n d i f v o i d main () { change a single line of code, our approach SPL automatically i n t x = secret(); converts any analysis formulated for traditional programs within the print (y); } i n t y = 0; popular IFDS framework for inter-procedural, finite, distributive, y = foo (x); subset problems to an SPL-aware analysis formulated in the IDE i n t foo ( i n t p) { print (y); framework, a well-known extension to IFDS. Using a full imple- # i f d e f H } mentation based on Heros, Soot, CIDE and JavaBDD, we show that p = 0; LIFT with SPL one can reuse IFDS-based analyses without chang- # e n d i f i n t foo ( i n t p) { ing a single line of code. Through experiments using three static r e t u r n p; r e t u r n p; analyses applied to four Java-based product lines, we were able to } } show that our approach produces correct results and outperforms (a) Example SPL (b) Product for :F ^ G ^ :H the traditional approach by several orders of magnitude. Figure 1: Example product line: secret is printed if F and H are Categories and Subject Descriptors F.3.2 [Logics and Meanings disabled but G is enabled of Programs]: Semantics of Programming Languages—Program analysis instance for the development of games and other applications for General Terms Design, Languages, Performance mobile devices. This is due to the tight resource restrictions of those devices: depending on the hardware capabilities of a certain mobile Keywords Software product lines, inter-procedural static analysis, device, it may be advisable or not to include certain features in a context sensitive, flow sensitive software product for that device, or to include a variant of a given feature. 1. Introduction Static program analyses are a powerful tool to find bugs in A Software Product Line (SPL) describes a set of software prod- program code [1–3] or to conduct static optimizations [4], and ucts as variations of a common code base. Variations, so-called it is therefore highly desirable to apply static analyses also to features, are typically expressed through compiler directives such as software product lines. With existing approaches, though, it is the well-known # ifdef from the C pre-processor or other means of often prohibitively expensive to reuse existing static analyses. The conditional compilation. Figure 1a shows a minimal example prod- problem is that traditional static analyses cannot be directly applied uct line that assigns values through different methods. Figure 1b to software product lines. Instead they have to be applied to pre- processed programs such as the one from Figure 1b. But for an SPL shows the product obtained by applying to the product line a pre- n processor with the configuration :F ^ G ^ :H, i.e., a product with with n optional, independent features, there are 2 possible products, feature G enabled and features F and H disabled. Software product which therefore demands thousands of analysis runs even for small lines have become quite popular in certain application domains, for product lines. This exponential blowup is particularly annoying because many of those analysis runs will have large overlaps for different feature combinations. It therefore seems quite beneficial to share analysis information wherever possible. In this work we introduce SPLLIFT, a simple but very effective Permission to make digital or hard copies of all or part of this work for personal or approach to re-using existing static program analyses without an classroom use is granted without fee provided that copies are not made or distributed LIFT for profit or commercial advantage and that copies bear this notice and the full citation exponential blowup. SPL allows programmers to transparently on the first page. To copy otherwise, to republish, to post on servers or to redistribute lift an important class of existing static analyses to software prod- to lists, requires prior specific permission and/or a fee. uct lines. Our approach is fully inter-procedural. It works for any PLDI’13, June 16–19, 2013, Seattle, WA, USA. analysis formulated for traditional programs within Reps, Horwitz Copyright c 2013 ACM 978-1-4503-2014-6/13/06. $15.00 and Sagiv’s popular IFDS [5] framework for inter-procedural, finite, • a mechanism for automatically and transparently converting any distributive, subset problems. In the past, IFDS has been used to IFDS-based static program analysis to an IDE-based analysis express a variety of analysis problems such as secure information over software product lines, flow [1], typestate [2, 3, 6], alias sets [7], specification inference [8], • a full open-source implementation for Java, and and shape analysis [9, 10]. SPLLIFT automatically converts any such analysis to a feature-sensitive analysis that operates on the entire • a set of experiments showing that our approach yields correct product line in one single pass. The converted analysis is formulated results and outperforms the traditional approach by several in the IDE framework [11] for inter-procedural distributed environ- orders of magnitude. ment problems, an extension to IFDS. In cases in which the original The remainder of this paper is structured as follows. In Section2, analysis reports that a data-flow fact d may hold at a given statement we introduce the IFDS and IDE frameworks, along with their s, the resulting converted analysis reports a feature constraint under strengths and limitations. Section3 contains the core of this paper; which d may hold at s. As an example, consider again Figure1. here we explain the automated lifting of IFDS-based analyses Imagine that we are conducting a taint analysis [1], determining to software product lines. Section4 explains how we take into whether information can flow from secret to print. In the tradi- account the product line’s feature model. In Section5 we discuss tional approach we would generate and analyze all 23 = 8 possible our implementation, while we present our experimental setup and products individually, eventually discovering that the product from results in Section6. The work presented in this paper bases itself Figure 1b may indeed leak the secret. SPLLIFT instead analyzes on previous work presented at the 2012 ACM SIGPLAN Workshop the product line from Figure 1a in a single pass, informing us that on Programming Languages and Analysis for Security [18]. In secret may leak for the configuration :F ^ G ^ :H (cf. Fig. 1b). Section7 we explain the differences to this paper along with the But a reduced analysis time is not the only advantage of a differences to other related work. feature-sensitive static analysis. In the area of software product lines, conditional-compilation constructs may add much complexity to the code, and can yield subtle and unusual programming mistakes [12, 2. The IFDS framework 13]. As an example, a plain Java program will not compile if it uses a potentially undefined local variable. In a Java-based software Our approach builds on top of the so-called IFDS framework by product line, any pre-processor would accept such a program; the Reps, Horwitz and Sagiv [5]. This framework defines a general programming problem would only manifest later, when the pre- solution strategy for the inter-procedural, flow-sensitive, and fully processed program is compiled. When the mistake is discovered, it context-sensitive analysis of finite distributive subset problems. In is laborsome to map the resulting plain-Java error message back to this section we present the general concepts behind this framework the original product line. Analyzing the product line directly, as in and illustrate them by an example. SPLLIFT, circumvents this problem. To obtain meaningful results, SPLLIFT further takes feature 2.1 Overview of the IFDS Framework models into account. A feature model defines a Boolean constraint The major idea of the IFDS framework is to reduce any program- that describes the set of all feature combinations that a user intends analysis problem formulated in this framework to a pure graph- to generate, the SPL’s valid configurations (or valid products). For reachability problem. Based on the program’s inter-procedural instance, if we were to evaluate the SPL from Figure 1a under the control-flow graph, the IFDS algorithm builds a so-called “exploded constraint F $ G (stating that the user intends to generate only super graph”, in which a node (s; d) is reachable from a selected products for which both F and G are either enabled or disabled), LIFT start node (s0; 0) if and only if the data-flow fact d holds at statement SPL would detect that the secret information cannot leak after s.