Method, apparatus and computer program for compiling source code

Abstract

The present disclosure relates to a method for compiling source code (CS) intended to generate an executable program (FW) to be executed on a programmable controller (CP), said method being implemented by an electronic device comprising at least one processor and a storage space. The method comprises:-a first compilation step (CS01) in which a code line of source code (CS) is transformed into a plurality of code lines in an intermediate code (LCI), and in which a call of at least one intermediate code line to a breakpoint control function (FBP) is added, a set of intermediate code lines, referred to as an intermediate program (ICP), is transmitted,-a second compilation step (CS02) in which the code line of the source code (CS) is transformed into a plurality of code lines in the intermediate code (LCI), and in which a call of at least one intermediate code line to the breakpoint control function (FBP) is added, wherein the intermediate program (ICP) is compiled into a language executable by the programmable controller to generate an executable program (FW).

Description

Technical Field

[0001] The present disclosure relates to a mechanism for controlling the execution of computer program code in a debug mode. The present disclosure more particularly relates to the control of the execution of computer program code written in one of the IEC61131 languages. Background Art

[0002] IEC61131 is a standard for programmable logic controllers (PLCs) that defines several programming languages for industrial automation. Specifically, the IEC61131-3 standard defines the following five programming languages: Ladder Diagram (LD), Structured Text (ST), Function Block Diagram (FBD), Instruction List (IL), and Sequential Function Chart (SFC). These programming languages provide flexibility for engineers and programmers to choose the most suitable method based on the complexity of the control task and their preferences. A programmable logic controller (PLC) is an industrial digital computer used as an automation controller for manufacturing processes, such as assembly lines or robotic devices. A PLC can emulate hard-wired relays, timers, and sequencers, which are replaced by software that calculates outputs based on values from inputs and internal memory. In the normal PLC software development process, the specifications of the system behavior are written before programming. The programmer writes a PLC program that should produce the expected output as a function of the inputs. In addition, the programmer needs to test whether the program meets the given specifications during the system verification process.

[0003] As in every development process, the generated program needs to be tested before being implemented in production mode. One feature available for such a testing process is the "breakpoint". A breakpoint in program debugging is a specified point at which the execution of the program in the code will pause, allowing the developer to inspect the state of the program, variables, and other relevant information. Breakpoints are a fundamental tool for debugging because they enable programmers to interactively analyze and troubleshoot their code during runtime. Breakpoints significantly allow stepping operations within the code, which can effectively ensure that the code meets the programmer's expectations.

[0004] To implement user breakpoints for the IEC61131 language (and all other compiled languages), the current state of the art basically provides two solutions:

[0005] - Using the hardware resources of some processors, which directly implement hardware breakpoints (automatically entering an exception mode when a given code address is reached),

[0006] - Manually replacing the source code opcode at the desired address with an undefined instruction, which will cause an exception mode to be entered when reached. This strategy is called a software breakpoint.

[0007] Until recently, PLC firmware (i.e., the PLC program implanted into a programmable logic controller (PLC)) was written in kernel mode into a specific operating system. When they mainly execute in the kernel of the PLC's operating system, it allows easy access to the exception mode (kernel mode, also known as supervisor mode or privileged mode), which is an operating mode in a computer system where the executing code usually has access to all hardware and can perform any operation). However, even in this case, implementing breakpoints requires specific knowledge of the processor exception mode and assembly code.

[0008] However, due to various considerations, including some important factors associated with the cybersecurity threats that a factory may encounter, using the kernel mode of the operating system for the firmware of the executing controller is no longer convenient. Therefore, it is desirable to find a solution for executing these programs in user mode (also known as user execution space). This additional constraint prevents the use of processor exceptions to execute the firmware. Although this may not be a problem when executing the firmware in production mode, it requires finding a new solution for allowing breakpoints to be implemented when executing the firmware in debug mode.

[0009] The present invention proposes a new solution to solve at least some of the above problems. Summary of the Invention

[0010] Therefore, according to a first aspect, the present disclosure relates to a method for compiling source code intended to produce an executable program to be executed on a programmable controller, the method being implemented by an electronic device including at least one processor and a storage space. The method includes:

[0011] - A first compilation step, in which lines of code of the source code are converted into multiple lines of code in intermediate code, and in which at least one call to a breakpoint control function is added to an intermediate code line, delivering a set of intermediate code lines called an intermediate program,

[0012] - A second compilation step, in which the intermediate program is compiled into a language executable by the programmable controller to produce an executable program.

[0013] Therefore, at runtime, when the executable program is running on another device (target device), a full software breakpoint solution is implemented by executing the breakpoint control function, which is responsible for checking whether a breakpoint has been added to the execution.

[0014] According to an aspect of the present disclosure, the first compilation step includes at least one iteration of the following steps:

[0015] - A step of obtaining the current line of code from the source code,

[0016] - A step of determining during debugging whether a breakpoint can be inserted into the current code line, and

[0017] - If it is determined that the current code line is a line where a breakpoint can be located:

[0018] - A step of converting the current code line into at least one intermediate code line,

[0019] - A step of inserting a call line into a breakpoint verification function within an intermediate code file,

[0020] - A step of inserting at least one intermediate code line into the intermediate code file immediately after the call line.

[0021] Thus, the positioning of the breakpoint can be adapted as a function of the source code itself, or as a function of a specific predefined breakpoint that the programmer wishes to locate. In addition, the determination step may include an iterative process that automatically excludes some lines of the source code that are not applicable to the breakpoint.

[0022] According to one aspect of the present disclosure, the method includes: obtaining a call identifier value, and the call identifier value is used as a parameter of a breakpoint check function.

[0023] Thus, according to the identifier inserted as a parameter of the breakpoint function call, the positions of various breakpoints can be accurately identified.

[0024] According to one aspect of the present disclosure, the call identifier value is a function of the call context of the breakpoint verification function.

[0025] According to one aspect of the present disclosure, the call context of the breakpoint verification function is determined as a function of the position of the current source code line, such that:

[0026] - If the current source code line is part of the same function as a previous source code line, then the call identifier value is the same as the previous call identifier value used for the previous source code line,

[0027] - If the current source code line forms part of the function of a previous source code line, then the call identifier value is different from the previous call identifier value used for the previous source code line.

[0028] According to one aspect of the present disclosure, the source code is written in one of the languages of IEC61131-3.

[0029] Thus, the method is applicable to breakpoint management for a set of specific real-time automaton languages.

[0030] According to a second aspect, the present disclosure relates to a method of executing an executable program obtained using the compilation method proposed herein, and the method is implemented by a programmable controller including at least one processor and a storage space, and the method includes at least one of the following iterations:

[0031] - An executable code line for calling a breakpoint control function is executed by a programmable controller,

[0032] - The existence of a breakpoint relative to a corresponding source code line is determined by a breakpoint checking function, and

[0033] - If a breakpoint exists, the current execution stack of the executable program is transmitted to an execution module connected to the programmable controller.

[0034] According to one aspect of the present disclosure, the step of determining the existence of a breakpoint by a breakpoint control function includes the step of attempting to obtain a semaphore such that when the semaphore is unavailable, the execution of at least one process of the executable program is stopped.

[0035] According to a third aspect, the present disclosure also relates to an apparatus for compiling source code intended to produce an executable program to be executed on a programmable controller, and the method is implemented by an electronic device including at least one processor and a storage space. Such an apparatus includes:

[0036] - A module for processing a first compilation, wherein a code line of the source code is converted into a plurality of code lines in intermediate code, and wherein at least one call to a breakpoint control function is added, and a set of intermediate code lines called an intermediate program is transmitted,

[0037] - A module for processing a second compilation, wherein the intermediate program is compiled into a language executable by the programmable controller to produce an executable program.

[0038] According to another aspect, the present disclosure relates to a computer program including instructions that, when such instructions are run by a processor, cause the method as described above to be implemented.

[0039] According to another aspect, the present disclosure relates to an apparatus for generating a computer program to be executed on a programmable logic controller, the apparatus including a module for managing breakpoints on controller software (also referred to as firmware) that is intended to be implemented on the programmable logic controller, and more specifically, including a module for generating intermediate code based on source code, the intermediate code including at least one call to a software breakpoint detection function, and a module for managing the execution of the software breakpoint detection function when the controller software is executed in a debug mode. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] More details are given in the following description with reference to the accompanying drawings, wherein:

[0041] Figure 1 The main components of the system according to the present disclosure are shown,

[0042] Figure 2Depicts the main steps of the compilation method according to the present disclosure,

[0043] Figure 3 Depicts the main steps of the execution method according to the present disclosure,

[0044] Figure 4 Shows an example of calls and corresponding stacks managed during execution. Detailed Description

[0045] As previously mentioned, the purpose of the present disclosure is to allow a source program written in one of the IEC61131 languages to operate with breakpoints when executed in the user execution space (as opposed to the kernel execution space) in a so-called debug mode (also known as step-by-step mode). It should be reminded that within the scope of the present disclosure, the user execution space refers to the environment where user-level applications and processes run on the controller. It is a part of the system memory separated from the kernel space, where the core operating system functions. The user space is where application software and some drivers execute, and each user space process runs in its own virtual memory space, usually with restrictions on accessing the memory of other processes. This separation between the user space and the kernel space is essential for providing memory protection and hardware protection from malicious or incorrect actions.

[0046] For clarity, according to the present disclosure, a source program (or source code) refers to high-level programming code written in one of the IEC61131 languages, and a debug execution mode with breakpoints can be enabled for this high-level programming code. An intermediate program (or intermediate code) refers to programming code (such as C or C++) obtained from the source program with a first compilation (transformation), and the first compilation is also called front-end compilation. The resulting intermediate code represents an intermediate representation, encapsulating the inherent logic and structural aspects of the original source code as well as additional features, as detailed below. This representation is suitable for subsequent optimization and transformation and plays a pivotal role in the management of breakpoints. The firmware (or executable program) refers to a binary file written in machine language (e.g., assembler), which is obtained from the intermediate program through a second compilation, and the second compilation is also called back-end compilation. The firmware is uploaded and executed by the controller.

[0047] Therefore, the present disclosure relates to two main aspects: the first aspect is to provide a new compilation method that allows some additional data to be inserted into the binary file produced and installed as the firmware of the controller, and the second aspect is to provide an execution method for these binary files to allow the user to add breakpoints during execution and perform regular stepping operations in the code.

[0048] According to the present disclosure, stepping means having knowledge of the call stack in the firmware (the binary file uploaded in the controller) when the code is executed. The implementation problem of this mode is that it means checking the call context when reaching a breakpoint. According to the present disclosure, this problem is solved by using unique identifiers inserted during the first compilation. According to the present disclosure, there are three possible stepping operations allowed:

[0049] - STEP IN: Move forward and stop at the next source code line. If the current line is a function call, enter the function and stop at the first line of the function.

[0050] - STEP OVER: Move forward and stop at the next source code line. If the current line is a function call, execute the function and stop when returning from the function.

[0051] - STEP OUT: Move and stop when exiting the current function.

[0052] In short, the method of the present disclosure works as follows: During the process of breakpoint management, breakpoints are placed at specific addresses within the compiled binary code, and the entire process is handled at the source code level. This involves inserting calls to a specified function, such as "s_check_breakpoint", at predetermined locations within the binary code. This insertion process is performed using a compilation module during the first compilation (which can also be used for, e.g., debugging). During runtime (during execution in debug mode), the "s_check_breakpoint" function is called, and its main purpose is to calculate the address of the caller. Subsequently, it compares this calculated address with the predefined breakpoint address. If there is a match, it indicates that the executable program has reached the specified breakpoint. To initiate an effective pause of the program execution, a semaphore-like mechanism is used. More specifically, according to the present disclosure, when a breakpoint is effectively placed, the executable program attempts to acquire a semaphore that is already in the "taken state". Utilizing the semaphore in this way allows for effectively pausing the current task or thread of the executable program. This method ensures a controlled and synchronized pause in the program execution, facilitating the inspection and debugging of the code at the breakpoint.

[0053] According to the present disclosure, as explained below, the insertion of a call to the specified function "s_check_breakpoint" can be automatically completed during the first compilation of the compilation module. The compilation module identifies (in the IEC61131 source code) the locations where breakpoints may be inserted (for use during execution in debug mode), and based on these locations, inserts calls to the "s_check_breakpoint" function. According to the present disclosure, the insertion of a call to the specified function "s_check_breakpoint" by the programmer before the compilation module is compiled can also be done manually by the programmer: in this case, the programmer pre-determines the locations (in the IEC61131 source code) where he wants to stop the executable program so that he can examine the various contents of variables and parameters relative to the breakpoints planned to be used.

[0054] Regarding the present disclosure, in connection with Figure 1 an exemplary system is described in which the proposed method can be implemented. The exemplary system includes a number of components that can communicate with each other via a direct link or via a communication network (wired or wireless). The first component is a compilation module CM, which can be part of a general development environment ED that a programmer must use to create a source program according to the IEC61131 language. For example, the development environment ED includes at least one development module DM, which allows editing code in one or more of the IEC61131 languages and stores the source program in a file FL. The file FL is used by the compilation module CM to transform the source program stored in the file into an intermediate language (e.g., in C or C++).

[0055] Then, the intermediate program in the intermediate language is converted into one or more binaries (firmware) executable by a programmable controller CP, which are capable of executing a class of languages. In one variant, depending on the effective implementation, several compilation modules can be used for the first compilation step and the second compilation step. Once compiled and linked to a given processing target, the (multiple) binaries are stored locally. The system also includes a communication module CM (allowing direct or indirect, as explained previously herein), in particular for uploading the binaries to the controller CP, which is used for testing purposes in this example. The controller CP can be a real controller or a virtual controller for simulating (mimicking) the functions of a controller. The binaries (IES) are uploaded to the real controller or to the virtual controller. The system also includes an execution module EM that allows the firmware to be executed in normal or debug mode.

[0056] At the beginning, at least one communication channel is established between the controller CP and the execution module EM, allowing the two to exchange parameters and data. In particular, the execution module EM can instruct the controller to execute all or part of the uploaded (patched) firmware FW, and the controller CP is capable of transmitting all or part of the execution result of the firmware (e.g., in the form of log lines, etc.). According to the present disclosure, considering a specific compilation method adopted for creating an intermediate program, the execution module EM can also be configured to initiate a breakpoint for the execution of the firmware, while the firmware is configured to receive a breakpoint identifier and step instructions from the execution module and transmit relevant execution data (especially the content of variables at the breakpoint).

[0057] As introduced previously herein, aspects of the present disclosure relate to a compilation method that allows obtaining an intermediate program from a source program generated by a software programmer. The intermediate program is written, for example, in the C or C++ language. This intermediate language is of course an intermediate language suitable for the PLC under discussion and can vary from one manufacturer to another.

[0058] The notable feature of the compilation method of the present disclosure is that some additional content is added to the conventional intermediate code generated by prior art methods. In fact, in prior art methods, the intermediate code is also generated from IEC61131-3 source programs. However, the code is optimized to produce a sufficient executable program, which means that no irrelevant material is included.

[0059] Different from prior art methods, the compilation method of the present disclosure adds at least one additional code line to the intermediate code. However, the additional code line is compiled (converted) from the intermediate code into binary executable code by a suitable compiler (which translates the intermediate code into assembly language), and the assembly language is subsequently converted into suitable machine code. The compilation / assembly chain from the intermediate language to the binary machine code (including or not included in a module) is typically provided by the manufacturer of the PLC. Figure 2 The main steps of the compilation method according to the present disclosure are shown. The method includes:

[0060] - A first compilation step CS01, in which the code lines of the source code CS are converted into multiple code lines in the intermediate code LCI, and in which at least one call to a breakpoint control function FBP is added to the intermediate code lines, transmitting a set of intermediate code lines called the intermediate program ICP,

[0061] - A second compilation step CS02, in which the intermediate program ICP is compiled into a language executable by a programmable controller to produce an executable program FW.

[0062] According to an embodiment, the added extra code lines have two types. The first type is a "function call" FCL to a dedicated function FBP (the specified function "s_check_breakpoint"). The second type is the code lines of the explicit function FBP, which is called by the "function call" FC lines. Additional data structures are also added to the intermediate computer program, as well as necessary additional functions, which will facilitate the information exchange between the firmware and the execution module in order to drive the execution (especially the stepping operation). Therefore, in addition to the code lines directly obtained from the source program, the intermediate program also includes at least one function call type line added to the code lines from the source program, several code lines of the function FBP that is shown to be called, and at least one data structure for breakpoint management. Other additional functions and the function FBP can be obtained through a compiled debug library, and a link is inserted into the intermediate code for this debug library.

[0063] In an embodiment, each line of the code lines from the source program is preceded by a function call FC. Therefore, in such an embodiment, when breakpoints are managed at the source code level, they are placed at specific addresses in the binary (compiled) code. At each of these areas, a call to the specific function "s_check_breakpoint" is inserted. This insertion is done at the compilation level by a compilation module. Therefore, when transforming the source code written in one of the IEC61131-3 languages into a C / C++ program, the following method is processed. This method includes at least one iteration of the following steps:

[0064] - Obtain the current code line written in the IEC61131-3 language,

[0065] - Determine whether a breakpoint can be inserted in the current code line during debugging, and

[0066] - When it is determined that the current code line can be a line where a breakpoint can be located:

[0067] - Transform (compile) the current code line (CLC) into at least one intermediate code line (LCI),

[0068] - Insert a call line (FCL) to the breakpoint check function (FBP) within the intermediate code file (FCI),

[0069] - Immediately insert at least one intermediate code line (LCI) within the intermediate code file (FCI) after the call line (FCL).

[0070] According to the present disclosure, as described above, the call line (FCL) to the breakpoint check function (FC) includes an identifier as an argument (“s_check_breakpoint”) to the call of the verification function. This identifier is, for example, an integer encoded according to a pre-parameterized length (e.g., 16 bits or 32 bits). In other words: s_check_breakpoint(uid).

[0071] When inserting the call line, in this embodiment, the compiler checks the insertion context of this line of code: the insertion context is the same as when the previous call line was inserted, in which case the value of the identifier (uid) is the same as the value of the previous call line; or the insertion context is different from the insertion context when the previous call line was inserted, in which case a different (new) and unique identifier is used. In this second case (using a different identifier), there are at least two different situations:

[0072] - Insert the new call line into a new function (i.e., the compiled code shows a new function that has not been called in the code before), and then generate a new call identifier value (uid) (because it is a new function that has never been called before),

[0073] - Or insert the new call line inside a function that has already been partially processed (e.g., it is a call line following the output of the function), then retrieve the value of the identifier previously used for this partially processed function and use it as the identifier (uid).

[0074] For illustrative and example purposes only, the following IEC61131-3 source code (written in the “structured text” language):

[0075] %MW1 := 1;

[0076] %MW2 := 2;

[0077] Adder(%MW3, %MW1, %MW2);

[0078] Result := %MW3;

[0079] FUNCTION_BLOCK Adder: integer

[0080] VAR_INPUT

[0081] c, a, b: integer;

[0082] END_VAR

[0083] c := a + b;

[0084] Adder := 0;

[0085] END_FUNCTION_BLOCK

[0086] After compilation with an intermediate language (such as C), the following intermediate code can be obtained:

[0087] #include <stdio.h>

[0088] #include <breakpointman.h>

[0089] int mw1, mw2, mw3, result;

[0090] s_check_breakpoint(123456);

[0091] mw1 = 1;

[0092] s_check_breakpoint(123456);

[0093] mw2 = 2;

[0094] s_check_breakpoint(123456);

[0095] Adder(mw3, mw1, mw2);

[0096] s_check_breakpoint(123456);

[0097] Result = mv3;

[0098] int Adder (int c, int a, int b)

[0099] {

[0100] s_check_breakpoint(78910);

[0101] c = a + b;

[0102] s_check_breakpoint(78910);

[0103] return 0;

[0104] }

[0105] As can be seen from the previous code lines, in the intermediate code in C language, each line that can be associated with a breakpoint in the source language has a call to the breakpoint control function in front of it. The identifier (uid) passed as an argument to this function call varies depending on the context. When in the main program, this identifier takes the example value "123456", and when in the adder function, this identifier takes the example value "78910". This way of preparing to call the breakpoint control function is interesting because it allows a stack to be built during the execution of the code, as described below. This enables the management of stepping operations (step over, step into, step out).

[0106] Of course, this simplified example of the C language transformation is not exhaustive and is only intended to illustrate the implemented process. In addition to inserting the call line into the s_check_breakpoint function, the intermediate code program also includes the implementation of such an s_check_breakpoint function and the data structures and functions required to manage the execution stack used during stepping operations, in the form of including the library "<breakpointman.h>".

[0107] Furthermore, as introduced previously in this document, the present disclosure also relates to a method for managing breakpoints. This method uses a call to the s_check_breakpoint function to determine whether a stop should be made during execution. The compiled firmware execution method implements an interlock mechanism to stop its execution when a breakpoint effectively exists. As described above, the firmware execution (in debug mode, with breakpoints) is performed via an execution module and a communication channel, which enables data to be exchanged between the module and the firmware. Figure 3 The main steps of the execution method according to the present disclosure are shown. The method includes at least one iteration of the following:

[0108] - The programmable controller CP executes the executable code line that calls the breakpoint control function FBP of ES01;

[0109] - The breakpoint check function FBP determines the existence of the ES02 breakpoint relative to the corresponding source code CS line; and

[0110] - If a breakpoint exists, the current execution stack of the executable program FW is transmitted ES03 to the execution module EM connected to the programmable controller.

[0111] Specifically, at startup, the firmware and the execution module exchange the data required to establish this communication channel. Then this channel is used to determine whether execution needs to be stopped using the "s_check_breakpoint" function. For example, when a breakpoint is set, the execution module sends the location to the firmware via the communication channel. This location indicates the section and line where the breakpoint is set. From this information (i.e., the location), the firmware calculates the address (@BKPT) corresponding to the assembler instruction in the application code of the firmware. This address instruction corresponds to the first instruction in the assembler on the program line where the breakpoint is set.

[0112] As a reminder, in the exemplary embodiment, each line of the program starts with the ASM_LABEL_DEBUG macro. However, due to compilation, the assembler instruction to call s_check_breakpoint is just before the first instruction in each line of the program. Note the address of this instruction in @FCT. The typical assembler instruction to call a function:

[0113] @FCT: bx r3 (arm) or call 0x30 (intel)

[0114] @FCT+4: first instruction after call to s_check_breakpoint

[0115] Therefore, if and only if @FCT+4 is equal to @BKPT, the existence of a breakpoint can be inferred. This is equivalent to the s_check_breakpoint test to stop the program at the desired breakpoint. When the @FCT instruction (e.g., "bx r3") is executed, the program switches to the s_check_breakpoint routine. Once B is completed, the 32-bit ARM processor returns to A with the next instruction @FCT+4. It can return because it has previously copied the @FCT+4 address to a special register, the link register (lr) (e.g., "mov lr, pc"). This register is responsible for storing the return address of the subroutine. A similar mechanism exists for the INTEL32-bit processor. In C, there is a function to retrieve the value contained in this register, regardless of the architecture.

[0116] At this stage, it is possible to detect breakpoints with s_check_breakpoint. This allows implementing the option to step forward in the program, as explained here. Therefore, the operation of the "s_check_breakpoint" function globally includes:

[0117] - A mechanism to stop execution if a breakpoint exists,

[0118] - A mechanism for maintaining knowledge of the execution stack described later, and this mechanism uses a unique identifier to call the "s_check_breakpoint" function.

[0119] The mechanism for stopping execution during a breakpoint event involves using a semaphore: when the "s_check_breakpoint" function is executed, it attempts to acquire the semaphore managed by, for example, the execution module.

[0120] If the semaphore can be acquired by the "s_check_breakpoint" function, this means there is no breakpoint (it can move itself). In this case, the function releases the semaphore and executes the corresponding code line.

[0121] If the semaphore cannot be acquired by the "s_check_breakpoint" function, this means there is a breakpoint. In this case, the "s_check_breakpoint" function is paused until the semaphore is released. Meanwhile, the content of the execution stack (i.e., including firmware execution variables and parameters) managed by the parallel firmware process is sent to the execution module so that it can be displayed. The transmission of the execution stack uses the communication channel established at firmware startup. Once the user (programmer) has examined the content, he selects an action:

[0122] - Continue execution without any additional breakpoints: the semaphore is released by the execution module, and firmware execution continues.

[0123] - Continue execution by performing a stepping operation:

[0124] - The semaphore is released by the execution module and then immediately requested again by the execution module after the release.

[0125] - This release triggers the execution of the code line corresponding to the breakpoint: the firmware releases the semaphore itself using the execution module and immediately returns, causing the "s_check_breakpoint" function to exit and the following code line to be executed. The fact that the firmware returns the semaphore allows the execution module to return the semaphore and thus prevent the next execution of the "s_check_breakpoint" function.

[0126] The continuous stepping operation implemented then consists of the repetition of the above two steps. In an alternative or additional example, instead of the execution module taking and releasing the semaphore, it is directly managed from the firmware itself via a firmware debugging process running in parallel with the main process (the main process being the process being debugged). Regardless of the position of the semaphore, the firmware debugging process running in parallel on the controller can, for example, be responsible for collecting breakpoint addresses from the execution module and obtaining the semaphore to send them to the main process. It continuously reads the breakpoint addresses (e.g., at a predetermined interval). When new data is available, it sends the data to a shared memory location or a message queue accessible by the breakpoint address. If no new data is available, it continues to check at regular intervals.

[0127] Furthermore, as described above, a mechanism is provided for maintaining knowledge of the execution stack. For the stepping operation, when a new cycle is executed, the firmware maintains knowledge of the user call stack. This is achieved by using unique identifiers that have been inserted during the compilation of the software. In an exemplary embodiment, when the execution module generates IEC1131 compiled language, it adds a unique identifier (e.g., a 32-bit integer) as a parameter to the s_check_breakpoint function. This identifier is the same within a given function and is guaranteed to be unique for each function by construction.

[0128] At execution time, the firmware places the first satisfied unique identifier in a LIFO (last in, first out) container in the cycle, and when s_check_breakpoint is called again, three cases are possible:

[0129] - The current id value is the same as one of the previous calls: The call is made within the same function;

[0130] - The current id value is different from the previous call, but the current ID value exists in the LIFO: This means the exit of the executed function (so the execution will usually stop in the case of STEP OUT), and thus the previous ID is removed from the LIFO.

[0131] - The current ID is different from the previous one and does not exist in the LIFO: This means the execution enters a new function (so it will not stop at this point in the case of STEP OVER execution, but continue execution until the previous ID is found again). In this case, the current ID is added to the LIFO.

[0132] Figure 4 Depicts the different cases that can be satisfied with respect to the stepping operation. In Figure 4In the illustrative example, it is assumed that the source code is written in structured text and has four parts of lines with source code (S1 to S4) including the source code (various Lx). The arrows (gray) show some possible transitions, depending on which STEP operation occurs. For example, depending on the STEP operation s_check_breakpoint, the execution may or may not stop. Examples of STEP IN are represented as: 2 -> 3 (from S1 to the callee 3), and from 3 -> 4 (from S3 to the callee S4). An example of STEP OVER is represented as: 2 -> 5 (from L2 to L3 staying in S1). Finally, examples of STEP OUT are represented as: 3 -> 5 (from S3 to the caller S1), and from 1 -> 7 (from S1L1 to the next S2). The identifier provided as a parameter to the S_CHECK_BREAKPOINT function is labeled "ID Sx". It can be noted that on the executed line S4L1, the stack (LIFO) includes variables and parameters from S1, S3, and S4.

[0133] Furthermore, as described above, the device DV for generating the computer program FW to be executed on the programmable logic controller CP may include an antenna system, for example, connected via an interface to a processing circuit including a processor and a memory. Alternatively, or as a variant of the antenna system, the necessary data (e.g., source program, predetermined parameters) may also be received via a communication link, thereby allowing the device to generate the computer program FW. The memory stores at least the instructions of the computer program according to the present disclosure. By performing this type of processing, in particular by implementing the data structures (filo list, identifier, compilation parameters) of the method according to the present disclosure, the processor of the device has been shown to be able to generate the computer program FW including the necessary structures to allow for the implementation of breakpoints in an efficient and low-weight manner. Such an effect is clearly not possible by attempting to manually intervene in the software in the debug mode, as this would require access to the kernel mode, as explained above.

[0134] In a preferred embodiment, a computer system or device includes one or more processors (which may belong to the same computer or different computers) and one or more memories (magnetic hard disks, optical disks, electronic memories, or any computer-readable storage medium), wherein one or more memories (magnetic hard disks, optical disks, electronic memories, or any computer-readable storage medium) storing a computer program product, in the form of a set of program code instructions to be executed, so as to implement all or part of the steps of the generation method. Alternatively, or in combination therewith, the computer system may include one or more programmable logic circuits (FPGA, PLD, etc.), and / or one or more application-specific integrated circuits (ASIC), etc., which are adapted to implement all or part of the steps of the generation method. In other words, the computer system includes a set of devices configured by software (a specific computer program product) and / or hardware (processors, FPGA, PLD, ASIC, etc.) to implement the steps of the generation method.

Claims

1. A method for compiling source code (CS) intended to produce an executable program (FW) to be executed on a programmable controller (CP), the method being implemented by an electronic device comprising at least one processor and a storage space, the method comprising: - A first compilation step (CS01), in which lines of code of the source code (CS) are transformed into multiple lines of code in intermediate code (LCI), and in which at least one call to a breakpoint control function (FBP) is added, and a set of lines of intermediate code called intermediate program (ICP) is transmitted, - A second compilation step (CS02), in which the intermediate program (ICP) is compiled into a language capable of being executed by the programmable controller to produce the executable program (FW).

2. The compilation method according to claim 1, wherein the first compilation step (CS01) comprises at least one iteration of the following steps: - A step of obtaining the current line of code from the source code (CS), - A step of determining whether a breakpoint can be inserted at the current line of code during debugging, and - If it is determined that the current line of code is the line in which the breakpoint is located: - A step of transforming the current line of code (CLC) into at least one line of intermediate code (LCI); - A step of inserting a call line (FCL) into the breakpoint verification function (FBP) within the intermediate code file (FCI); - A step of inserting the at least one line of intermediate code (LCI) into the intermediate code file (FCI) immediately after the call line (FCL).

3. The compilation method according to claim 2, wherein the method comprises: Obtain a call identifier value, which is used as a parameter of the breakpoint check function.

4. The compilation method according to claim 3, wherein the call identifier value is a function of the call context of the breakpoint verification function.

5. The compilation method according to claim 4, wherein the call context of the breakpoint verification function is determined according to the position of the current line (CLC) of the source code, such that: - If the current source code line is part of the same function as the previous source code line, the call identifier value is the same as the previous call identifier value used for the previous source code line, - If the current source code line forms part of the function of the previous source code line, the call identifier value is different from the previous call identifier value used for the previous source code line.

6. The method according to any one of claims 1 to 5, wherein the source code is written in one of the IEC61131-3 languages.

7. A method for executing an executable program (FW) obtained using the compilation method according to any one of claims 1 to 6, the method being implemented by a programmable controller (CP) comprising at least one processor and a storage space, the method comprising at least one iteration of the following: - Executing (ES01) by the programmable controller (CP) an executable code line that calls the breakpoint control function (FBP); - Determining (ES02) by the breakpoint check function (FBP) the presence of a breakpoint relative to the corresponding source code (CS) line; and - If there is a breakpoint, the current execution stack of the executable program (FW) is transmitted (ES03) to the execution module (EM) connected to the programmable controller.

8. The execution method according to claim 7, wherein the step of determining the existence of a breakpoint by the breakpoint control function (FBP) includes a step of attempting to obtain a semaphore such that when the semaphore is unavailable, the execution of at least one process of the executable program (FW) is stopped.

9. An apparatus for compiling source code (CS) intended to produce an executable program (FW) to be executed on a programmable controller (CP), the method being implemented by an electronic device including at least one processor and a storage space, the apparatus comprising: - A module for processing a first compilation, wherein the lines of code of the source code (CS) are transformed into multiple lines of code in intermediate code (LCI), and wherein at least one call to the breakpoint control function (FBP) is added to transmit a set of intermediate code lines called an intermediate program (ICP). - A module for processing a second compilation, wherein the intermediate program (ICP) is compiled into a language capable of being executed by the programmable controller to produce the executable program (FW).

10. A computer program including instructions which, when run by a processor, cause the implementation of the method according to any one of the preceding claims.

Images