EP3100160A1

EP3100160A1 - Method for code disambiguation

Info

Publication number: EP3100160A1
Application number: EP15706863.6A
Authority: EP
Inventors: Patrice Martinez; Gaël LALIRE; Landry Stéphane ZENG EYINDANGA
Original assignee: Bull SA
Current assignee: Bull SA
Priority date: 2014-01-27
Filing date: 2015-01-27
Publication date: 2016-12-07
Also published as: US20160350092A1; FR3016979A1; FR3016979B1; US10255050B2; WO2015110771A1

Abstract

The invention relates to a method for disambiguating an executable code file comprising a symbol table, characterised in that it comprises the following steps: reading a disambiguation configuration comprising at least one symbol-renaming instruction; renaming symbols from a symbol table according to at least one symbol-renaming instruction of the disambiguation configuration; and saving the file with the code disambiguated according to the disambiguation configuration.

Description

Code disambiguation method

TECHNICAL FIELD OF THE INVENTION

The invention relates to a method of disambiguation of code and in particular executable code.

Executable code in the context of this application will be understood as any loadable byte sequence for execution by an operating system. In particular, but not exclusively, ELF (executable an Linkable Format, for executable and linkable Format), a.out and PE (Portable Executable, for Portable Executable) formats are targeted. In general, are also referred to the so-called executable files and so-called libraries, implied executable code.

STATE OF THE PRIOR ART

[0003] Some applications involve the implementation of a plurality of libraries. Each library exports functions that can be used by other executables or libraries that reference it. These other files are said to depend on the library. Each exported function has a name that identifies it.

[0004] Problems arise at least in the following cases:

Two different libraries export a function with the same name,

A file E depends on two libraries libA which exports a function fa and NbB which exports a function fb. The function fa calls a function fc of a version v1 of a library NbC. libA therefore depends on a version v1 of NbC, the function fb calls a function fc of a version v2 of NbC. NbB therefore depends on a v2 version of NbC. In this case, at runtime, during a call to fa or fb there is an ambiguity on the version of the function fc to load. In this case the program fails and stops with an error message or the program behavior is undefined.

In the state of the art when such a problem is detected, it is carried out, if possible, a "refactoring" of source code. This means that one Performs a new development cycle to resolve naming ambiguities. In the example cited, it would be necessary to change the source code of one of the versions of the library NbC to rename the function fc. This involves:

to have the source code of the library, this is rarely the case, - to create another specific version of the library, thus complicating the management of the development of NbC and E.

Such a refactoring is also a heavy operation since it involves a new validation of all the code that is impacted, that is to say, a recovery of all unit tests and functional to verify the absence of impact on the behavior of the application using the modified code.

This represents a significant workload and difficult to automate.

SUMMARY OF THE INVENTION

The invention aims to remedy all or part of the disadvantages of the state of the art identified above, and in particular to provide means for adapting versions of a library without having to access or modify its source code.

In the invention is used a configuration file that specifies, symbol renaming instructions. An instruction is used to select one or more symbols in a symbol table and specify, for the symbols, to select a renaming rule. The selection of symbols is, for example, according to their nature (exported or imported) and / or by name. In the same way, the configuration file contains instructions for renaming dependencies.

For this purpose, one aspect of the invention relates to a method of disambiguating an executable code file comprising a table of symbols, characterized in that it comprises the following steps:

reading a disambiguation configuration including at least one symbol renaming instruction,

renaming symbols of a symbol table according to at least one symbol renaming instruction of the disambiguation configuration. saving the disambiguated code file according to the disambiguation configuration.

In addition to the main features which have just been mentioned in the preceding paragraph, the method / device according to the invention may have one or more additional characteristics among the following, considered individually or according to the technically possible combinations:

the executable code file having a dependency table, the method comprises the following steps:

reading a disambiguation configuration including at least one dependency renaming instruction, renaming dependency dependencies according to at least one dependency renaming instruction of the disambiguation configuration; a renaming instruction has at least:

a criterion for selecting a symbol or a dependency, a derivation rule of a name depending at least on the name of the symbol;

that a selection criterion of a symbol includes a symbol type code according to whether to select an exported symbol or an imported symbol;

a selection criterion is a regular expression type mask applied to the name of a symbol or dependency;

a derivation rule takes into account version information of the executable code file to be produced.

The invention also relates to a digital storage device storing a program executable by a machine and composed of instructions carrying out the method according to a combination of the above-mentioned characteristics.

BRIEF DESCRIPTION OF THE FIGURES

Other features and advantages of the invention will emerge on reading the description which follows, with reference to the appended figures, which illustrate:

Figure 1 is a schematic view of an executable file;

Figure 2, an illustration of steps of the method according to the invention. For clarity, identical or similar elements are identified by identical reference signs throughout the figures.

The invention will be better understood by reading the description which follows and examining the figures that accompany it. These are presented as an indication and in no way limitative of the invention.

DETAILED DESCRIPTION OF AN EMBODIMENT

In Figure 1 is illustrated, schematically, the structure of an executable file. Figure 1 shows an executable file. Such a file is usually recorded on storage means. Such a file is usually loaded into working memory for the purpose of interpreting its contents by a microprocessor. Here the use of the term interpretation does not presume the nature of the contents of the file. This is binary code that can be loaded into memory.

The file 1 01 executable comprises a zone 1 01 header. The header 1 01 describes the structure of the file. Among others the header 1 01 indicates, via different fields, offsets of different sections of the file 1 01 executable. A particular first field 1 02 of the header 1 01 gives the offset of a section 103 symbol table. An offset is conventionally a relative byte distance at the beginning of the file or at the end of the header.

A symbol is a reference to a code or data area in an executable file. A symbol is a way of describing an area to read or write.

The table symbol section 103 is usually structured in table, each row of the table corresponding to a symbol. A row has at least three columns:

A column 1 04 name of the symbol,

A column 1 05 type of the symbol,

A column 1 06 offset of the symbol.

The name of the symbol is used as input of the symbol table, that is to say as identifier of the symbol when executing the executable file 01, or when using the file 01 01 executable for editing links in an executable code production process. The type specifies whether the symbol is imported or exported. The symbol is exported if it can be used by another executable file than the one containing the symbol table. The symbol is imported if you have to search for the corresponding code or data area in another executable file than the one containing the symbol table.

The column 1 06 offset of the symbol has an offset if the symbol is exported. If the symbol is imported, then column 1 06 offset includes:

Either an indirection to a row of a dependency table Either a name of an executable file containing the code or the data of the symbol to be imported. In this second case, the symbol table is also a table of dependencies.

[0021] A dependency table is, in a simplified manner, an indexed list of executable file names. The knowledge of the offset of the dependency table, via a field of the header 1 01 for example, and the knowledge of an index, via column 1 06 offset of the symbol table, provides access to the name executable file.

Figure two shows a step 201 of reading a disambiguation configuration. A disambiguation configuration is saved in a disambiguation file. Any or all of the parameters of the disambiguation configuration file could be provided on the command line.

The method according to the invention is implemented by a processing computer 301 comprising a microprocessor 302 connected to storage means 303 via a bus 304. The method according to the invention therefore corresponds to instruction codes recorded on the means 303 storage and designated by a file name. The method according to the invention is therefore invoked via the name of the corresponding file. This name is, for example, entered in a command window, also called console. This name can be followed by one or more parameters.

When lending an action to a microprocessor or a computer, it is actually performed by the microprocessor controlled by instruction codes loaded into a working memory.

[0025] A disambiguation configuration file comprises: An identifier of a file to be processed, as well as a new name for the file resulting from the processing,

One or more renaming instructions

None, one or more rename settings.

A renaming instruction is either a symbol or a dependency. Thus a renaming instruction to the following structure:

A designation code depending on whether you want to rename a symbol or an addiction,

A selection mask interpreted according to the designation code

A rule of derivation of a new name.

The designation codes according to whether one wishes to rename a symbol or a dependency are arbitrary values, for example:

1 for a symbol,

2 for an addiction.

A mask is for example according to one of the following syntaxes for all of the renaming instructions:

A full name of a symbol, in this case we look for a symbol whose name exactly matches,

A mask of type SQL, with wildcards

_ for one and only one character

% any character in any number from zero to no limit

A file selector type mask with wildcards:

? for one and only one character

* any character in any number from zero to no limit

A regular expression.

This list of syntax examples is not limiting.

The case of the regular expression is interesting because it makes it possible to capture parts of a chain that can be used to construct a new name for the symbol.

If one wishes to use several selection mask syntaxes in the same disambiguation configuration file, then one must add a information to the structure of the renaming instruction, this added information being a code for specifying the manner in which the mask is to be interpreted.

A derivation rule is, for example:

A string compatible with the printf C-language statement, the other parameters of the printf instruction being, in a predetermined order, the name of the symbol or dependency, the renaming parameters. We quoted an instruction of the language C but one can also use other language like C # and in this case the instruction String. Format A replacement string in the context of using a regular expression. In this case we cite as an example the preg_replace function of the PHP language.

In step 201 the computer 301 loads a 305 disambiguation configuration file. This allows the computer 301 to know:

a file 306 to be processed, it is a file recorded on the means 303 for storing the computer 301 for processing,

The name of the file to produce,

Rename parameters,

A renaming instruction list,

In step 201, the processing computer 301 proceeds to a loading step 202 of the list of symbols. For simplicity we place ourselves in the case where the table of symbols is also a table of dependencies. In the loading step 202, the computer 301 accesses the symbol table of the file 306 to be processed via the header of this file.

Once the symbol table is loaded, the computer 301, in a step 203 analyzes each symbol to determine if one of the renaming instructions corresponds to the symbol. The analysis is as follows

if there is a renaming rule whose designation code is 1 and whose selection mask matches the name of the symbol

replace the name of the symbol with the result of applying the rule of derivation corresponding to the rule

end if

if the symbol is exported if there is a renaming rule whose designation code is 2 and whose selection mask corresponds to the dependency of the symbol

replace the name of the dependency with the result of applying the rule of derivation corresponding to the rule

end if

These pseudo instructions are executed for each symbol of the symbol table and, where appropriate, for each dependency of the dependency table.

From the analysis step 203 of each symbol the computer 301 proceeds to a step 204 of recording the modified file according to the disambiguation configuration loaded in the step 201 of loading the configuration into a file whose name was also loaded in step 201.

In a variant of the invention, the selection of the symbols to be processed is according to whether they are imported or exported. In this case, a rename statement includes, in its structure, a code specifying whether it applies to exported, imported, or both symbols.

In one example, a derivation instruction of the type is considered:

'{0} ν {1}'

This means, for example that the new name of the symbol will be: old name + v + first renaming parameter. The first renaming parameter, provided in the disambiguation configuration file, is, for example, a version number of the processed file.

In an integrated variant of the invention, only a renaming instruction is used for the exported symbols. This rule is to rename all exported symbols taking into account the version of the processed file. This version is obtained, with the choice and in a nonlimiting way:

By a command line parameter

- By a configuration file

By analyzing the header of the processed file

By analyzing the name of the processed file, which is then of the fileName.version type. extension. In this integrated variant, the result file of the processing is a file named according to a version number. For example, this name is filename.version. extension or:

filename is the name of the file to be processed

- extension is the extension of the file to be processed, if it has one

version is the value of the version parameter.

If this name is the same as the name of the file to be processed then either the resulting file of the process replaces the original file, or the resulting file of the process is saved in another location, ie in another directory.

In the integrated variant of the renaming instructions can be integrated into the executable code corresponding to the invention. In this case they are loaded together with the executable code corresponding to the invention.

So if we consider an E file that matters:

a function fa of a LibA file which itself imports an add function of a version 1 of a LibC file

a function fb of a LibB file which itself imports an add function of a version 2 of the LibC file

Then we perform the following disambiguation operations:

LibC to LibC.vl by renaming the exported symbols to post fixants by v1, or _v1 or equivalent string taking into account at least the version of the result file of the process

LibC to LibC.v2 by renaming the exported symbols to postfixed by v2, or _v2 or equivalent string taking into account at least the version of the result file from processing - LibA to LibA.vl by renaming symbols imported from LibC by postfixing them in a manner consistent with the renaming performed to obtain LibC.vl and renaming the dependency to LibC in dependence on LibC.vl

LibB to LibB.vl by renaming the symbols imported from LibC by post-fixing them in a consistent manner with the renaming done to obtain LibC.v2 and renaming the dependency to LibC in dependence on LibC.v2

E to E by renaming: The LibA addiction in LibA.vl

The LibB dependency on LibB.vl

In the illustrative example above, changing the names of LibA and LibB, and thus processing E, is optional. Describing it is part of the illustration of the invention.

Thus from the point of view of the file E ambiguities related to the calls to the function "add" have been removed. The objectives of the invention are therefore well achieved.

A digital storage device has been described for storing a program executable by a machine and composed of instructions implementing the method according to the invention as a hard disk, but it is understood that it can be any medium , removable or not. For example it could be a USB key, a CD, DVD or "BlueRay Disc". This list is not exhaustive.

Claims

1. A method of disambiguating an executable code file comprising a table of symbols, characterized in that it comprises the following steps:

reading (201) a disambiguation configuration comprising at least one symbol renaming instruction,

renaming (202, 203) symbols of a symbol table according to at least one symbol renaming instruction of the disambiguation pattern.

recording (204) of the disambiguated code file according to the disambiguation configuration

2. Method of disambiguation according to one of the preceding claims, characterized in that, the executable code file having a table of dependencies, the method comprises the following steps:

reading a disambiguation configuration including at least one dependency renaming instruction,

renaming dependencies of the dependency table according to at least one dependency renaming instruction of the disambiguation configuration.

3. Method of disambiguation according to one of the preceding claims, characterized in that a renaming instruction comprises at least:

a criterion for selecting a symbol or a dependency,

a derivation rule of a name depending at least on the name of the symbol.

4. Method of disambiguation according to claim 3, characterized in that a selection criterion of a symbol comprises a symbol type code according to whether to select an exported symbol or an imported symbol.

5. disambiguation process according to one of claims 3 or 4 characterized in that a selection criterion is a regular expression type mask applied to the name of a symbol or dependency.

6. Method of disambiguation according to one of claims 3 to 5, characterized in that a derivation rule takes into account a version information of the executable code file to produce.

7. A digital storage device (303) storing a program executable by a machine and consisting of instructions implementing the method according to one of the preceding claims.