1 Abstract Multi-core software should be partitioned under differ-ent constraints e.g., balanced execution load on cores, timing behavior and optimized level of communication/synchronization among different system components. The objective is to efficiently distribute the processes onto multi-core hardware such that the sys-tem has reduced communication/synchronization complexity. Moreover, a bad distribution strategy during migration from single-to multi-core and from multi-to many-core hardware does not always return the expected performance gain. This paper presents two novel AI-based approaches for optimal distribution (minimal inter-core communication inspite of no dead-line misses) of software system on multi-core hardware architecture. We discuss the comparisons of our machine learning solutions based on unsupervised and reinforcement learning. We share the benefits and limitations of using unsupervised learning and reinforcement learning based on our experience.

With the advent of multi-core ECUs and hardware fusion in the automotive domain, the tooling environment to support multi-core software development has gained significance. Especially, tools that can provide an early indication about the architectural behavior before the existence of the code. Such domain specific tool platforms, which enable analyses (e.g., data-consistency) and optimizations (memory management, task-to-core mapping, timing simulations and distribution) are not easily available. The commercial solutions available on the market cannot be applied generally with off the shelf optimization options. Therefore, at Bosch we have developed a tool platform that bridges the open source and commercial solutions to support analysis and optimizations of multi-core system development. This paper provides an overview of the different optimization use cases and developed tool platform.

Extensible languages allow incremental extensions of a host language with domain specific abstractions. Debuggers for such languages must be extensible as well to support debugging of different language extensions at their corresponding abstraction level. As such languages evolve over time, it is essential to constantly verify their debugging behavior. For this purpose, a General Purpose Language (GPL) can be used, however this increases the complexity and decreases the readability of tests. To reduce continuous verification effort, in this paper, we introduce DeTeL, an extensible Domain-Specific Language (DSL) for testing extensible language debuggers.

Language extension enables integration of new language constructs without invasive changes to a base language (e. g., C). Such extensions help to build more reliable software by using proper domain-specific abstractions. Language workbenches significantly reduce the effort for building such extensible languages by synthesizing a fully-fledged IDE from language definitions. However, in contemporary tools, this synthesis does not include interactive debugging for programs written with the base language or its extensions. This paper describes a generic framework for extensible debuggers that enables debugging of the language extensions by defining mappings between the base language and the language extensions. The architecture is designed for extensibility, so debug support for future extensions can be contributed with little effort. We show an implementation of our approach for mbeddr, which is an extensible version of the C programming language. We also discuss the debugger implementation for non-trivial C extensions such as components. Finally, the paper discusses the extent to which the approach can be used with other base languages, debugger backends and language workbenches.

Multi-level debugging of extensible languages requires lifting program state to the extension level while translating stepping commands to the base-level. Implementing such bi-directional mappings is feasible for languages with a low abstraction level (e. g., C). However, language workbenches support language stacking with a bottom-up approach from lowto high-level (e. g., domain-specific) languages. This way, generation of code written with these high-level languages is incremental. However, languages can have more than one generator, which is selected depending on the execution environment. On the other hand, provision of such flexibility makes multi-level debugging much harder. In this paper, we present an approach on how to enable debugging for such multi-staged generation environments. The approach is illustrated by mbeddr, which is an extensible C language.

Synchronization errors in parallel programs are not limited to race conditions involving accesses to single variables. Absence of these errors does not guarantee that programs are error free. However, many of the remaining errors cannot be recognized without a higher level of abstraction for the communication patterns. This paper discusses two types of high-level error scenarios, namely non-atomic protection and lost-updates, and presents a static framework to detect situations where such synchronization anomalies can manifest themselves.

Multi-threaded parallel programs perform accesses to shared variables, which require application of a synchronization strategy. Absence of synchronization among threads may lead to error situations, such as data races. Data races, which involve concurrent accesses to a single shared variable, are categorized as low-level. Synchronization strategies to alleviate lowlevel data races do not guarantee freedom from data races on a higher-level of abstraction. In this paper, we discuss some scenarios where accesses to a group of variables may result in data races. Further, we discuss a method to statically detect such situations and describe its integration into Bauhaus tool suite.

Die Entwicklung und Wartung von nebenlaufigen Programmen ist schwierig und fehleranfallig. Fehlende oder falsche Synchronisation kann zu komplizierten Fehlerszenarien fuhren, die dem Quelltext nur schwer anzusehen sind, jedoch katastrophale Auswirkungen auf die Programmausfuhrung haben konnen. Durch statische Programmanalyse konnen alle Quelltextpositionen identifiziert werden, an denen bestimmte Fehler, wie z.B. Data Races, auftreten konnen. Ein Data Race existiert in einem nebenlaufigen Programm, wenn mehrere Threads auf eine gemeinsam genutzte Variable (Shared Variable) zugreifen und folgendes gilt: (1) mindestens ein Thread schreibt auf die Variable und (2) die einzelnen Zugriffe finden ohne Synchronisation statt. Data Races konnen zu inkonsistenten Daten im Speicher fuhren und schwerwiegende Folgen fur die korrekte Ausfuhrung des Programms haben. Fuhren beispielsweise zwei Threads gleichzeitig die Operation g = g + c fur eine globale Variable g aus, so hangt der resultierende Wert von g davon ab, in welcher Reihenfolge die beiden Threads den alten Wert von g lesen und den neuen Wert in den Speicher ablegen. Zur Erkennung von Data Races wurden in den letzten Jahren eine Vielzahl von Verfahren erforscht. In dem Projekt Bauhaus [2] wurde ein Verfahren zur statischen Analyse basierend auf dem LocksetAlgorithmus [1] implementiert. Aufgrund der prinzipiellen Unentscheidbarkeit des Problems muss eine statische Analyse jedoch die Menge der tatsachlichen Data Races uberschatzen. Es wird eine Anzahl an falsch positiven Warnungen erzeugt, die in keiner realen Ausfuhrung des analysierten Programms tatsachlich eintreten konnen. Fur den praktischen Einsatz der Analysen ist deshalb ein Werkzeug notig, das die Warnungen in geeigneter Form fur einen Benutzer aufbereitet. Der Benutzer muss manuell untersuchen konnen, welche Warnungen tatsachliche Data Races darstellen und welche gefiltert werden sollten. Zu diesem Zweck wird in diesem Papier das Werkzeug RaceVis vorgestellt. Es wurde als Teil des Bauhaus-Projekts als Plugin fur die Entwicklungsplattform Eclipse implementiert.

Creating multiple threads for performance gain is not only common for complex computations on supercomputers but also for ordinary application programs. Multi-threaded/parallel programs have many advantages but also introduce new types of errors that do not occur in purely sequential programs. Race conditions are one important class of these special problems because the effects of race conditions occur nondeterministically and range from incorrect results to unexpected program behaviour. This paper presents RCanalyser, a tool for the detection of race conditions, which is based on a Must_Locksanalysis using a flexible interface for the integration of different points-to analyses. As the problem of detecting race conditions is NP-hard in the general case, the tool is restricted to the detection of so-called data races [1]. The tool is able to analyse C/C++programs that use thread APIs for the implementation and synchronization of concurrent units. We applied the tool to a set of real programs, which use the POSIX thread API, and present results and statistics.

The maintenance and evolution of critical software with high requirements for reliability is an extremely demanding, time consuming and expensive task. Errors introduced by ad-hoc changes might have disastrous effects on the system and must be prevented under all circumstances, which requires the understanding of the details of source code and system design. This paper describes Bauhaus, a comprehensive tool suite that supports program understanding and reverse engineering on all layers of abstraction, from source code to architecture.

This survey examines research in the area of race detection tech-niques. Diverse flavors of on-the-fly, ahead-of-time and post-mortem techniques are covered. This survey tries to present advantages and limitations exhibited by different race detection techniques.