Las colocaciones en el Español Moderno versus las del PCIC

Python scripting has been present in GDB since its version 7.0 in 2009. It allows extending GDB behavior through an external API, instead of writing C code. This modularity has multiple benefits:

Stable The API only exports stable functionalities, backward compatible over future releases. This is in opposition with the internal C code, for which no stability guarantees are provided. Hence, an extension developed in C may break after any new release and must be verified each time.

Focused/documented The Python API was designed with the explicit goal of allowing user scripting. Hence, it provides a focused set of functionalities and hides GDB’s internal complexity. In addition, all the elements of the API are documented and accessible online1_.

1 Debugging with GDB– Python API, http://sourceware.org/gdb/current/onlinedocs/gdb/ Python-API.html

4.1 source-level debugger back-end Efficient development Python is a widely used programming language, fully flavored2 and used for large-scaled development such as the YouTube website. This is invaluable in comparison with GDB’s original scripting capabilities which could only automate repetitive console command-lines.

External Python extension can be distributed independently from GDB, without requir- ing a software recompilation. In comparison, C improvements must be distributed either as source-code patches or through pre-compiled binaries.

On the downside of GDB’ Python API, we can remark its youth. Indeed, at the beginning of this thesis work (early 2011), it was only a few years old, and some API bindings were found missing (we discuss in the next paragraph how we solved that issue).

Extending GDB’s Python APIIn the previous paragraph we praised Python develop- ment and disregarded the C side. However, it is important to note that only extensions can be developed in Python; all the core, low-level and maybe performance-critical work must be done in C. In particular, the bindings between GDB internals and Python environments must also be written in this language.

In order to implement our model-centric debugger in Python, we extended GDB Python interface to support all of our needs. In particular, we contributed the following patches:

• allow Python to detect that multiple breakpoints were hit when the execution stops3_,

• add a “getter” to retrieve the process— inferior in GDB parlance—currently selected4_,

• add Python notifications when a process exits5_{, or when a shared-library is} loaded6_,

• and finally, the most important patch of the serie was the introduction of the concept of finish breakpoint7_{, crucial to our implementation design. We describe} its rationals in the following section.

All of these patches were documented, tested against regressions and reviewed by GDB maintainers. (The review process looks at code correctness, coding style, docu- mentation quality, etc.) After cycles of updates/reviews, the patches met expectations and hence were accepted for inclusion in the official code-base. Committing these patches in the GNU repository meant that, from the next version onwards, the official GDB releases would include our improvements. Furthermore, it also implies that, thanks to the non-regression tests, the community would ensure that the functionalities keep working as expected along the time.

2 Python Success Stories,http://www.python.org/about/success/

3 https://www.sourceware.org/ml/gdb-cvs/2011-09/msg00085.html

4 https://www.sourceware.org/ml/gdb-cvs/2011-09/msg00086.html

5 https://www.sourceware.org/ml/gdb-cvs/2011-10/msg00019.html

6 https://www.sourceware.org/ml/gdb-cvs/2011-10/msg00034.html

building blocks for a model-centric debugger

In the following sections, we discuss the core of our model-centric debugger imple- mentation, starting with the mechanisms used to capture the state of abstract machines. 4.2 capturing the abstract-machine state and its evolution

In order to monitor the state of the abstract machine running the application, the debugger needs to hook each of the operations affecting its state. In this section, we present the capture mechanism we implemented and analyze its efficiency. Then, we compare it against two alternative mechanisms and finally summarize their respective interests.

API Interception with Breakpoints and Debug Information

The information-capture mechanism we implemented for our debugger prototype relies on debugger-internal breakpoints set on the state-modifying operations of the environment API (e.g., function symbols in C-based languages). Internal breakpoints are transparent for the user, who is not notified of the brief execution stop. When they are triggered, the debugger parses operation arguments with the help of the API definition and architecture calling conventions. Then, it decides to continue the execution or gives the control back to the user interface. Figure4.2presents a sequence diagram of these interactions. The concept of finish breakpoint was introduced in GDB Python API to programmatically catch the return point of a function. This allows the interception of output and updated parameters. If further information is required, and if application source-code and debug information (e.g., Dwarf structures [Fre10]) are available, the debugger can use this knowledge to intercept implementation-specific knowledge about the abstract machine and better represent its state.

Evaluation The key benefit of this approach is that is does not require any additional debugging support from the application or from the programming-model supportive environment. Furthermore, the debugger can be developed with no cooperation with the supportive environment team. In the context of prototype development, this is a significant advantage

The portability of this mechanism depends on whether the debugger relies or not on source-code hooks, in addition to API interception. If it does not happen, the debugger might be version/vendor independent. Otherwise there is a strong dependency between the debugger and the supportive environment which limits the portability.

However, the main drawback of that approach is that the internal breakpoints may slow down application execution. This is particularly true for data exchange breakpoints, which can be triggered very frequently in a communication-intensive application. We further discuss this point in the concluding remarks in Section4.5.