Misplaced Pages

Virtual Execution System

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

In engineering , debugging is the process of finding the root cause , workarounds and possible fixes for bugs .

#532467

45-478: The Virtual Execution System ( VES ) is a run-time system of the Common Language Infrastructure CLI which provides an environment for executing managed code . It provides direct support for a set of built-in data types, defines a hypothetical machine with an associated machine model and state, a set of control flow constructs, and an exception handling model. To a large extent, the purpose of

90-532: A P-code machine or virtual machine , that hide even the processor's instruction set . This is the approach followed by many interpreted languages such as AWK , and some languages like Java , which are meant to be compiled into some machine-independent intermediate representation code (such as bytecode ). This arrangement simplifies the task of language implementation and its adaptation to different machines, and improves efficiency of sophisticated language features such as reflective programming . It also allows

135-503: A joke , conflating the two meanings of bug (biological and defect), the story indicates that the term was used in the computer field at that time. Similarly, the term debugging was used in aeronautics before entering the world of computers. A letter from J. Robert Oppenheimer , director of the WWII atomic bomb Manhattan Project at Los Alamos, used the term in a letter to Dr. Ernest Lawrence at UC Berkeley, dated October 27, 1944, regarding

180-587: A culture of a "zero-defects" mandate, where people might be tempted to deny the existence of problems so that the result would appear as zero defects . Considering the collateral issues, such as the cost-versus-benefit impact assessment, then broader debugging techniques will expand to determine the frequency of anomalies (how often the same "bugs" occur) to help assess their impact to the overall system. Debugging ranges in complexity from fixing simple errors to performing lengthy and tiresome tasks of data collection, analysis, and scheduling updates. The debugging skill of

225-414: A functionality available on low-cost embedded processors, an On-Chip Debug Module (OCDM), whose signals are exposed through a standard JTAG interface . They are benchmarked based on how much change to the application is needed and the rate of events that they can keep up with. In addition to the typical task of identifying bugs in the system, embedded system debugging also seeks to collect information about

270-618: A hierarchy of runtime systems, with the CPU itself—or actually its logic at the microcode layer or below—acting as the lowest-level runtime system. Some compiled or interpreted languages provide an interface that allows application code to interact directly with the runtime system. An example is the Thread class in the Java language . The class allows code (that is animated by one thread) to do things such as start and stop other threads. Normally, core aspects of

315-438: A language's behavior such as task scheduling and resource management are not accessible in this fashion. Higher-level behaviors implemented by a runtime system may include tasks such as drawing text on the screen or making an Internet connection. It is often the case that operating systems provide these kinds of behaviors as well, and when available, the runtime system is implemented as an abstraction layer that translates

360-484: A runtime system may also perform support services such as type checking , debugging , or code generation and optimization . The runtime system is also the gateway through which a running program interacts with the runtime environment . The runtime environment includes not only accessible state values, but also active entities with which the program can interact during execution. For example, environment variables are features of many operating systems, and are part of

405-406: A runtime system that implements the execution model's behavior. Most scholarly papers on runtime systems focus on the implementation details of parallel runtime systems. A notable example of a parallel runtime system is Cilk , a popular parallel programming model. The proto-runtime toolkit was created to simplify the creation of parallel runtime systems. In addition to execution model behavior,

450-555: A runtime system. One possible definition of runtime system behavior, among others, is "any behavior not directly attributable to the program itself". This definition includes putting parameters onto the stack before function calls, parallel execution of related behaviors, and disk I/O . By this definition, essentially every language has a runtime system, including compiled languages , interpreted languages , and embedded domain-specific languages . Even API -invoked standalone execution models, such as Pthreads ( POSIX threads ), have

495-684: A single task (or small range of tasks), and the platform is chosen specifically to optimize that application. Not only does this fact make life tough for embedded system developers, it also makes debugging and testing of these systems harder as well, since different debugging tools are needed for different platforms. Despite the challenge of heterogeneity mentioned above, some debuggers have been developed commercially as well as research prototypes. Examples of commercial solutions come from Green Hills Software , Lauterbach GmbH and Microchip's MPLAB-ICD (for in-circuit debugger). Two examples of research prototype tools are Aveksha and Flocklab. They all leverage

SECTION 10

#1732851842533

540-412: Is a stub . You can help Misplaced Pages by expanding it . Run-time system In computer programming , a runtime system or runtime environment is a sub-system that exists in the computer where a program is created, as well as in the computers where the program is intended to be run. The name comes from the compile time and runtime division from compiled languages , which similarly distinguishes

585-427: Is actively used by recognized publishers in copy-protection schemas, but is also used by malware to complicate its detection and elimination. Techniques used in anti-debugging include: An early example of anti-debugging existed in early versions of Microsoft Word which, if a debugger was detected, produced a message that said, "The tree of evil bears bitter fruit. Now trashing program disk.", after which it caused

630-660: Is assigned a value. As another example, some such tools perform strong type checking when the language does not require it. Thus, they are better at locating likely errors in code that is syntactically correct. But these tools have a reputation of false positives, where correct code is flagged as dubious. The old Unix lint program is an early example. For debugging electronic hardware (e.g., computer hardware ) as well as low-level software (e.g., BIOSes , device drivers ) and firmware , instruments such as oscilloscopes , logic analyzers , or in-circuit emulators (ICEs) are often used, alone or in combination. An ICE may perform many of

675-544: Is implemented by the Pthreads runtime system (this runtime system is often the OS kernel). As an extreme example, the physical CPU itself can be viewed as an implementation of the runtime system of a specific assembly language. In this view, the execution model is implemented by the physical CPU and memory systems. As an analogy, runtime systems for higher-level languages are themselves implemented using some other languages. This creates

720-442: Is the case of using an application programming interface (API) to interact with a runtime system. The calls to that API look the same as calls to a regular software library , however at some point during the call the execution model changes. The runtime system implements an execution model different from that of the language the library is written in terms of. A person reading the code of a normal library would be able to understand

765-464: The C language is a particular set of instructions inserted by the compiler into the executable image. Among other things, these instructions manage the process stack, create space for local variables, and copy function call parameters onto the top of the stack. There are often no clear criteria for determining which language behaviors are part of the runtime system itself and which can be determined by any particular source program. For example, in C,

810-483: The operating system (OS), among others. The compiler makes assumptions depending on the specific runtime system to generate correct code. Typically the runtime system will have some responsibility for setting up and managing the stack and heap , and may include features such as garbage collection , threads or other dynamic features built into the language. Every programming language specifies an execution model , and many implement at least part of that model in

855-735: The VES is to provide the support required to execute the Common Intermediate Language CIL instruction set. The Common Language Runtime (CLR) implements the VES as defined in the Common Language Infrastructure (CLI) standard. Other notable implementations of the CLI such as Mono and Portable.NET include their own VES implementations. The .NET Micro Framework includes the .NET Micro Framework Interpreter as their VES implementation. This computer-programming -related article

900-459: The application(s) running within that runtime environment. Any other code that tries to run, or any failures in the application(s), will break the runtime environment. Breaking the runtime environment in turn breaks the OS, stopping all processing and requiring a reboot. If the boot is from read-only memory, an extremely secure, simple, single-mission system is created. Examples of such directly bundled runtime systems include: The runtime system of

945-457: The computer processes involved in the creation of a program (compilation) and its execution in the target machine (the runtime). Most programming languages have some form of runtime system that provides an environment in which programs run. This environment may address a number of issues including the management of application memory , how the program accesses variables , mechanisms for passing parameters between procedures , interfacing with

SECTION 20

#1732851842533

990-482: The execution model implemented by the runtime system. For example, the trap instruction is one method of switching execution models. This difference is what distinguishes an API-invoked execution model, such as Pthreads, from a usual software library. Both Pthreads calls and software library calls are invoked via an API, but Pthreads behavior cannot be understood in terms of the language of the call. Rather, Pthreads calls bring into play an outside execution model, which

1035-428: The initial problem happened. In those cases, memory debugger tools may be needed. In certain situations, general purpose software tools that are language specific in nature can be very useful. These take the form of static code analysis tools . These tools look for a very specific set of known problems, some common and some rare, within the source code, concentrating more on the semantics (e.g. data flow) rather than

1080-471: The input of the program may need to be simplified to make it easier to debug. For example, a bug in a compiler can make it crash when parsing a large source file. However, after simplification of the test case, only few lines from the original source file can be sufficient to reproduce the same crash. Simplification may be done manually using a divide-and-conquer approach, in which the programmer attempts to remove some parts of original test case then checks if

1125-427: The invocation of the runtime system into an invocation of the operating system. This hides the complexity or variations in the services offered by different operating systems. This also implies that the OS kernel can itself be viewed as a runtime system, and that the set of OS calls that invoke OS behaviors may be viewed as interactions with a runtime system. In the limit, the runtime system may provide services such as

1170-455: The library's behavior by just knowing the language the library was written in. However, a person reading the code of the API that invokes a runtime system would not be able to understand the behavior of the API call just by knowing the language the call was written in. At some point, via some mechanism, the execution model stops being that of the language the call is written in and switches over to being

1215-400: The operating states of the system that may then be used to analyze the system: to find ways to boost its performance or to optimize other important characteristics (e.g. energy consumption, reliability, real-time response, etc.). Anti-debugging is "the implementation of one or more techniques within computer code that hinders attempts at reverse engineering or debugging a target process". It

1260-413: The person who is doing the debugging. Generally, high-level programming languages , such as Java , make debugging easier, because they have features such as exception handling and type checking that make real sources of erratic behaviour easier to spot. In programming languages such as C or assembly , bugs may cause silent problems such as memory corruption , and it is often difficult to see where

1305-410: The problem still occurs. When debugging in a GUI , the programmer can try skipping some user interaction from the original problem description to check if the remaining actions are sufficient for causing the bug to occur. After the test case is sufficiently simplified, a programmer can use a debugger tool to examine program states (values of variables, plus the call stack ) and track down the origin of

1350-569: The problem(s). Alternatively, tracing can be used. In simple cases, tracing is just a few print statements which output the values of variables at particular points during the execution of the program. In contrast to the general purpose computer software design environment, a primary characteristic of embedded environments is the sheer number of different platforms available to the developers (CPU architectures, vendors, operating systems, and their variants). Embedded systems are, by definition, not general-purpose designs: they are typically developed for

1395-489: The programmer can be a major factor in the ability to debug a problem, but the difficulty of software debugging varies greatly with the complexity of the system, and also depends, to some extent, on the programming language (s) used and the available tools, such as debuggers . Debuggers are software tools which enable the programmer to monitor the execution of a program, stop it, restart it, set breakpoints , and change values in memory. The term debugger can also refer to

Virtual Execution System - Misplaced Pages Continue

1440-497: The proto-runtime approach. Notable early examples of runtime systems are the interpreters for BASIC and Lisp . These environments also included a garbage collector . Forth is an early example of a language designed to be compiled into intermediate representation code; its runtime system was a virtual machine that interpreted that code. Another popular, if theoretical, example is Donald Knuth 's MIX computer. In C and later languages that supported dynamic memory allocation,

1485-557: The recruitment of additional technical staff. The Oxford English Dictionary entry for debug uses the term debugging in reference to airplane engine testing in a 1945 article in the Journal of the Royal Aeronautical Society. An article in "Airforce" (June 1945 p. 50) refers to debugging aircraft cameras. The seminal article by Gill in 1951 is the earliest in-depth discussion of programming errors, but it does not use

1530-426: The runtime environment. The object file, on one hand, may be missing information from the runtime environment that will be resolved by linking . On the other hand, the code in the object file still depends on assumptions in the runtime system; for example, a function may read parameters from a particular register or stack location, depending on the calling convention used by the runtime environment. Another example

1575-410: The runtime environment; a running program can access them via the runtime system. Likewise, hardware devices such as disks or DVD drives are active entities that a program can interact with via a runtime system. One unique application of a runtime environment is its use within an operating system that only allows it to run. In other words, from boot until power-down, the entire OS is dedicated to only

1620-601: The runtime system also included a library that managed the program's memory pool. In the object-oriented programming languages , the runtime system was often also responsible for dynamic type checking and resolving method references. Debugging For software , debugging tactics can involve interactive debugging, control flow analysis, log file analysis , monitoring at the application or system level, memory dumps , and profiling . Many programming languages and software development tools also offer programs to aid in debugging, known as debuggers . The term bug , in

1665-695: The same program to be executed on any machine without an explicit recompiling step, a feature that has become very important since the proliferation of the World Wide Web . To speed up execution, some runtime systems feature just-in-time compilation to machine code. A modern aspect of runtime systems is parallel execution behaviors, such as the behaviors exhibited by mutex constructs in Pthreads and parallel section constructs in OpenMP . A runtime system with such parallel execution behaviors may be modularized according to

1710-416: The semantics of a particular program and the runtime environment is reflected by the different ways of compiling a program: compiling source code to an object file that contains all the functions versus compiling an entire program to an executable binary. The object file will only contain assembly code relevant to the included functions, while the executable binary will contain additional code that implements

1755-431: The sense of defect, dates back at least to 1878 when Thomas Edison wrote "little faults and difficulties" in his inventions as "Bugs". A popular story from the 1940s is from Admiral Grace Hopper . While she was working on a Mark II computer at Harvard University, her associates discovered a moth stuck in a relay that impeded operation and wrote in a log book "First actual case of a bug being found". Although probably

1800-428: The setup of the stack is part of the runtime system. It is not determined by the semantics of an individual program because the behavior is globally invariant: it holds over all executions. This systematic behavior implements the execution model of the language, as opposed to implementing semantics of the particular program (in which text is directly translated into code that computes results). This separation between

1845-402: The syntax, as compilers and interpreters do. Both commercial and free tools exist for various languages; some claim to be able to detect hundreds of different problems. These tools can be extremely useful when checking very large source trees, where it is impractical to do code walk-throughs. A typical example of a problem detected would be a variable dereference that occurs before the variable

Virtual Execution System - Misplaced Pages Continue

1890-419: The system, or perhaps a scheduled new release might render the change(s) unnecessary. Not all issues are safety-critical or mission-critical in a system. Also, it is important to avoid the situation where a change might be more upsetting to users, long-term, than living with the known problem(s) (where the "cure would be worse than the disease"). Basing decisions of the acceptability of some anomalies can avoid

1935-492: The term bug or debugging . In the ACM 's digital library, the term debugging is first used in three papers from 1952 ACM National Meetings. Two of the three use the term in quotation marks. By 1963 debugging was a common-enough term to be mentioned in passing without explanation on page 1 of the CTSS manual. As software and electronic systems have become generally more complex,

1980-410: The typical software debugger's tasks on low-level software and firmware . The debugging process normally begins with identifying the steps to reproduce the problem. This can be a non-trivial task, particularly with parallel processes and some Heisenbugs for example. The specific user environment and usage history can also make it difficult to reproduce the problem. After the bug is reproduced,

2025-552: The various common debugging techniques have expanded with more methods to detect anomalies, assess impact, and schedule software patches or full updates to a system. The words "anomaly" and "discrepancy" can be used, as being more neutral terms , to avoid the words "error" and "defect" or "bug" where there might be an implication that all so-called errors , defects or bugs must be fixed (at all costs). Instead, an impact assessment can be made to determine if changes to remove an anomaly (or discrepancy ) would be cost-effective for

#532467