BACKGROUND

Byte endianess is an attribute of data storage and retrieval. Big endian data or variables may be stored in memory in opposite byte order from little endian data or variables. Little endian data may be stored with the least significant byte in the lowest memory byte address while big endian data may be stored with the most significant byte in the lowest memory byte address. Big and little endian variables having the same value may be identical in CPU registers but may have differing order in memory.

Source code that is written using one byte endianess convention may not be executed on a platform using another endianess convention without recognizing the differing order of how some data are stored in memory. The following C code provides an example:

{int i = 0x12345678;char c = *((char*)&i);}

The â€œcâ€ will be 0x12 if the code is compiled and run on a big endian architecture but the â€œcâ€ will be 0x78 if the code is compiled and run on a little endian architecture. Thus, to execute code written in one endianess convention on a computer system platform of another endianess convention may require endian conversion. This can be difficult when, for example, the source code includes unions or casts a first pointer (which points to data consisting of multiple bytes) to a second pointer (which points to data consisting of a single byte). Pointers can create difficulties because some bi-endian compilers do not track byte order through pointers, such as void pointers, and do not produce diagnostics for potential byte order change through such pointers. Thus, pointers and the like can lead to unforeseen byte order incompatibilities.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of embodiments of the present invention will become apparent from the appended claims, the following detailed description of one or more example embodiments, and the corresponding figures, in which:

FIG. 1 is a block diagram, including pseudo code, for a method in an embodiment of the invention.

FIG. 2 is a block diagram, including pseudo code, for a method in an embodiment of the invention.

FIG. 3 is a block diagram of a method in an embodiment of the invention.

FIG. 4 is a system block diagram for use with an embodiment of the invention.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. Well-known circuits, structures and techniques have not been shown in detail to avoid obscuring an understanding of this description. References to â€œone embodimentâ€ , â€œan embodimentâ€ , â€œexample embodimentâ€ , â€œvarious embodimentsâ€ and the like indicate the embodiment(s) so described may include particular features, structures, or characteristics, but not every embodiment necessarily includes the particular features, structures, or characteristics. Further, some embodiments may have some, all, or none of the features described for other embodiments. Also, as used herein â€œfirstâ€ , â€œsecondâ€ , â€œthirdâ€ and the like describe a common object and indicate that different instances of like objects are being referred to. Such adjectives are not intended to imply the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner. Also, for clarity many example embodiments discussed herein address a compiler (e.g., C/C++ compiler) and its application to source code but embodiments of the invention are not necessarily so limited. For example, while embodiments include analytic code, such as an analytic tool included in a compiler, other embodiments may include analytic code included in other forms of code.

In one embodiment of the invention, code (e.g., compiler, tool) may generate information so a code portion, which includes a pointer value in a first endian format (e.g., big endian), can be properly initialized and executed on a platform having a second endian format (e.g., little endian).

FIG. 1 includes source code 110 and a visual representation of executable code 150. Code 110 may be susceptible to a â€œduplication problem.â€ Specifically, code 110 includes code portions 111, 112. Each portion includes an instance of global variable â€œg.â€ Global variable â€œgâ€ may be initialized twice by conventional compilers: once in code portion 111 (int*_attribute_((bigendian)) g=&i1) and once again in code portion 112 (int*_attribute_((bigendian)) g=&i2). Initialization includes, for example, the process of defining variables by assigning initial values to variables/data structures in a program. Code portions 111, 112 include pointers ((int*_attribute_((bigendian)) g=&i1) and (int*_attribute_((bigendian)) g=&i2)) that have big endian attributes but which respectively point to different addresses. Each address has a big endian attribute. Those addresses relate to two different objects ((int_attribute_((bigendian)) i1=1;) and (int_attribute_((bigendian)) i2=2;)). A compiler (e.g., bi-endian compiler) may attempt to convert source code 110 from big endian format or convention to code (e.g., executable code) suitable for a platform having little endian format. To do so, the compiler might perform, for example, a byteswap operation on big endian global variable â€œgâ€ in both portions 111 and 112. This may lead to a â€œduplication problemâ€ because â€œgâ€ is converted from big endian to little endian during the first endian conversion and then â€œgâ€ is converted from little endian back to big endian in a second conversion. Thus, the duplication problem may occur because â€œgâ€ is converted twice, thereby reversing the needed conversion from big endian to little endian.

A more specific description of how code 110 might lead to the duplication problem follows. Both source files 111, 112 define global big-endian variable â€œgâ€ . A conventional compiler may initialize global big-endian variable â€œgâ€ based on different link time constants, even though the address of the link time constant (e.g., i1 or i2) is not known until at link time or after link time (i.e., after compile time). The compiler may not know which particular value of â€œgâ€ is taken by the link editor or system loader. Thus for each portion 111, 112 the compiler generates a swap operation for â€œgâ€ , even though â€œgâ€ is a pointer variable that cannot be fully initialized (i.e., correctly initialized) until after compile time. Later, the link editor may only take one instance of â€œgâ€ resulting in two swap operations that are applied to single instance of â€œgâ€ .

One embodiment of the invention solves the duplication problem as follows:

{If (g_shadow == FALSE){Byteswap(g);g_shadow = TRUE;} else /* g has been swapped once so do nothing */}

Generally, the above pseudo code illustrates that an embodiment of the invention may use a â€œshadow variableâ€ to ensure global variable â€œgâ€ is converted (e.g., byteswapped) one time and that subsequent attempts to convert â€œgâ€ are suppressed. Upon the initial conversion of â€œgâ€ the variable â€œg_shadowâ€ is changed from â€œFALSEâ€ to â€œTRUE.â€ Afterwards, the conversion function (e.g., byteswap function) is suppressed because it is conditioned upon â€œg_shadowâ€ being set to â€œFALSE.â€

Thus, in one embodiment of the invention, for each global variable initialized with a link time constant of non native byte order the compiler may generate, within an application, a variable (e.g., invisible â€œshadow variableâ€ ). Shadow variables may be allocated inside a special shadow section so the shadow variables do not interfere with application variables. For example, a reference to a shadow variable may be placed together with a reference to the original variable. Initially, some or all shadow variables may be initialized with a â€œFALSEâ€ value meaning that the corresponding real application variable has not been swapped yet. Later, during the data initialization process, a â€œTRUEâ€ value may be placed into each shadow variable the first time a byteswap operation is applied to the corresponding original variable. Once the shadow variable is equal to â€œTRUEâ€ all consecutive swap operations for the original variable may be suppressed. Thus, in one embodiment of the invention the shadow variable â€œshadowsâ€ the global variable status indicating whether the global variable has or has not been byteswapped and helps ensure the global variable is byteswapped just once.

Returning to FIG. 1, code 150 is a visual representation of compiled code produced from source code 110 using an embodiment of the invention. For global variable â€œgâ€ code (e.g., compiler) may generate shadow variable â€œg_shadowâ€ in both code portions 151 and 152 because both of these portions correlate to portions of source code that include â€œgâ€ (i.e., code portions 111, 112). The â€œg_shadowâ€ variable is allocated from the â€œ.initdata_shadowâ€ section. The initial value of the â€œg_shadowâ€ variable is â€œFALSE.â€ Using code, such as a linker, symbolic references to â€œgâ€ may be converted (e.g., relocated) from a weak instance of â€œgâ€ (see schematic block 170) to a strong instance of â€œgâ€ (see schematic block 160) via schematic arrows 154, 155, 157, 159. A â€œweakâ€ designation may allow a program, for example, to change a variable's location during program execution. In contrast, a â€œstrongâ€ designation may not allow the program to change the variable's location during program execution. The strong definition of the variable may change the location defined by the weak variable, but not vice versa.

For the same reasons discussed above regarding â€œgâ€ , symbolic weak references to â€œg_shadowâ€ (block 175) may also be relocated to a single strong instance of â€œg_shadowâ€ (schematic block 165) via schematic arrows 156, 158. This relocation may be based on relocation information, provided by the compiler that coincides with the arrows that provide relocation direction in block 150. The code version that includes the relocated references to â€œgâ€ and â€œg_shadowâ€ is not shown in FIG. 1 but will be addressed with regard to FIG. 2. Later in a post-compile data initialization process, the first byteswap operation may be applied for â€œgâ€ (which was relocated via relocation information coinciding with arrow 155) and may put â€œTRUEâ€ at â€œg_shadowâ€ (which was relocated via relocation information coinciding with arrow 156). Then, when the process encounters the second byteswap operation for â€œgâ€ (which was relocated via relocation information coinciding with arrow 159) â€œg_shadowâ€ already has a â€œTRUEâ€ value (which was relocated via relocation information coinciding with arrow 158) and the swap operation is consequently not performed. Thus, in an embodiment â€œgâ€ is swapped just once and holds the correct value.

FIG. 2 includes an embodiment of the invention. Method 200 includes source code portion 205, which is analogous to portion 110 of FIG. 1. In block 210 the application is compiled. The compiler may generate initialization data when bi-endian functionality is enabled. The initialization data or information provided by the compiler may include the shadow variables, swap g references, and relocation information related to the shadow variables and swap g references. The compiler may place this initialization data into special Executable and Linking Format (ELF) sections named â€œ.initdataâ€ and â€œ.initdata_shadowâ€ , as indicated in block 215. Block 215 is analogous to portion 151 of FIG. 1. Depending on compiler options, this .initdata section may be placed in a loadable segment or a comment segment.

In block 220 other object files, such as portion 152 of FIG. 1, are treated in a similar fashion as block 215 to generate more .initdata sections. Then, in block 225 the linker may combine .initdata sections and relocate g swap and shadow variables (based on relocation information provided by the compiler) in a manner indicated by the arrows in FIG. 1. The .initdata sections may come from various object files and may place the .initdata sections in the linked binary.

In block 230 the code is post-processed using a post-link tool that, in one embodiment of the invention, may be included in the compiler. In other embodiments the post-link tool is separate from the compiler. The post-link tool may read the .initdata section of the executable image and perform initialization for data with values not computed correctly during linking (e.g., global variable addresses such as the â€œgâ€ variable). Since there might be unresolved references left over, the tool may check if a location does not have relocations, such as those discussed in relation to FIG. 1, associated with it. In that case, the correct value may only be detected during runtime and the swap may not be performed here but instead in block 245 (see below). Otherwise, the data that the address points to may be byteswapped as indicated in block 235 based on the initialization information provided by the compiler. Note that in block 235 some byteswaps have now occurred (e.g., long swapped(&i1)) and some entries from block 215 (e.g., g entry) have been removed. A single section_.initdata section exists due to relocations that occurred previously.

In blocks 240 and 245, dynamic runtime initialization may occur. If there are unperformed byteswaps left from the build in block 230 (e.g., as may occur with dynamically linked applications), they may be performed in block 245 where they are either done by, for example, a runtime initialization routine (e.g., provided by the compiler) which is statically linked with the executable or by a modified operation system (OS) loader before the application enters user code. In the case of runtime initialization, it may be required that data is located to a read-write (R/W) section to get loaded by the OS. These byteswaps may be possible due to the initialization information provided by the compiler.

In block 250 verification may occur. For example, upon application startup a check may be performed to ensure there are no remaining unresolved .initdata records left. Doing so may avoid program malfunctions due to missing endianess corrections inside initialized data. The compiler may generate a runtime check that ensures initialization has been done properly. For an example of such a runtime check, the compiler may create a big-endian â€œguardâ€ variable for each compilation unit. The â€œguard variableâ€ may be initialized with a known link time constant value and a routine, which checks if this value has been swapped. If no so such swap occurred, then the application may terminate with an error condition. Otherwise, the application may proceed in block 255.

Thus, various embodiments of the invention concern solutions for data initialization that cannot be fully resolved at compile time. For example, a global variable (e.g., â€œgâ€ from FIG. 1) may hold an address of another global variable. In that case the exact value to be assigned to the global variable may not be known until the linking stage. Another example of data initialization that cannot be fully resolved at compile time concerns applications that are linked dynamically, where the final values are known only after the dynamic linking stage at run-time. If the actual initializing value is supposed to have reverse byte order it should be swapped at some stage following dynamic linking and prior to program execution. Yet another example of data initialization that cannot be fully resolved at compile time concerns commonly used Application Binary Interfaces (ABIs) that allow weak definitions of variables. Such weak definitions allow declaring a variable more than once and letting the linker or loader decide which instance of the object is actually taken.

Various embodiments of the invention are tools based and may use a standard ELF file format. This may allow a user to use unmodified ELF based tools like linkers and operating system (OS) loaders with embodiments of the inventions.

Thus, in one embodiment of the invention a programmer desiring to port big endian code to run on a little endian platform (or vice versa) need not rewrite his or her application to run completely in a native single endian mode. Instead, portions of the source code can be designated with a particular endian format, such as components that require the big endian format to interact with network packets. Embodiments of the invention may then provide data that will allow for proper initialization of code portions at a later time. These code portions may include pointer values in a first endian format (e.g., big endian) which must later execute on a platform having a second endian format (e.g., little endian). Various embodiments of the invention provide automatic adjustment of endianess of statically initialized objects, including pointer objects. Some embodiments resolve address ambiguities caused by multiple allocated objects. Also, some embodiments provide runtime detection of missing endianess correction during, for example, application startup. Some embodiments use special compiler generated information to describe non-compile time constant big-endian pointer values. Various embodiments use a post-process tool to correct endianess after a link process has completed. Additional embodiments use special application start-up code, which can correct endianess in case of dynamically linked applications.

FIG. 3 is a block diagram of a method in an embodiment of the invention that may address, for example, difficulties caused by analytic code (e.g., bi-endian compiler). One such difficulty concerns compilers that do not track byte order through void pointers. A void pointer may include pointers that point to a value that has unknown type. Another difficulty may include the situation where byte order changes are lost through casting pointers to or from pointers. A â€œcastâ€ may include a programmer-specified data conversion from one type to another, such as a conversion from integer to floating point. As a result of these example difficulties, some compilers cannot produce diagnostics (e.g., diagnostic reports, prompts, messages, information) that identify potential byte order changes that occur through void pointers. These difficulties can lead to runtime issues. To address these problems, various embodiments of the invention help identify problematic regions of code where, for example, a particular byte order is cast away through void pointers. More specifically, embodiments of the invention may alert the user to potential problematic casts through void pointers, in effect associating a particular void with a byte order region so the user can address the conversion through code modification.

In block 305 of FIG. 3 a programmer may use code (e.g., tools, compiler) to mark regions of code (e.g., data structures) as little or big endian. As explained herein, some regions may be designated as, for example, big endian due to their use with network packets and the like. The compiler may also identify a void pointer is present. In block 310 the endian format may be identified. In block 315, if the void pointer is located in a code section that has been marked big endian, the compiler may create internally a â€œbig-endian void.â€ In block 320, if the void pointer was located in a little endian designated code portion the compiler may create a â€œlittle-endian void.â€ While the standard void type may match any language type, a byte order specific void (e.g., â€œbig-endian voidâ€ or â€œlittle-endian voidâ€ ) may only match, for example, data (e.g., non-aggregate data) with the same byte order and data (e.g., aggregate data) declared (i.e., defined) in the context of the same default byte order. Thus, in block 325 the presence of a mismatch is determined. In block 330, if there is no mismatch then the match may be allowed. However, in block 335 when there is a mismatch the compiler may issue a diagnostic reporting the mismatch (unless the diagnostic is disabled). For example, if a standard void pointer points from a big endian value to a small endian value no issue is ordinarily raised because void pointers are pointers that point to a value that has unknown type (and thus also an undetermined length and undetermined dereference properties). However, such an attempted match with a â€œbig-endian voidâ€ may be noted in a diagnostic (block 340) and brought to the programmer's attention where he or she could address the matter in block 345.

Use of the void type name, such as big-endian void, has the byte order attribute of the default byte order implicitly or explicitly (see block 305) assigned to the code region. A typedef may be used to create a void name type for a big and little endian void based on the typedef of the respective default byte order.

Some embodiments of the invention concern a different type void pointer. Specifically, in order to support source conversion to be byte order neutral a family of void types may be created for which the size of the data is captured by the bit size of the data appended to the void name, such as â€œvoid32â€ or â€œvoid64.â€ In a manner similar to that explained regarding method 300, these types match types of the same bit size. The source code may be modified to use these names and then the compiler will enforce the size constraint.

Thus, in some embodiments of the invention when the compiler performs a pointer conversion it may determine and issue a diagnostic when any of several situations arise. For example, a diagnostic may be produced when explicitly or implicitly converting to a void pointer from a different byte ordered type (e.g., converting from a big endian value to a little endian value via a void pointer). An â€œexplicitâ€ conversion may occur where, for example, the programmer explicitly writes a cast expression such as:

{int beint;void *p = (void*)&beint; // convert from big-endian int pointer tovoid pointer}

An â€œimplicitâ€ conversion is similar but may include no cast expression as follows:

{void *p = &beint; // convert from big-endian int pointer to voidpointer}

Compilers may produce fewer diagnostics for explicit conversions since a cast indicates to the compiler the programmer's actions are likely intentional. However, byte order can be lost through void pointer conversion so, in one embodiment of the invention, a diagnostic may be produced despite the explicit nature of the conversion.

Diagnostics (e.g., reports) may thus be produced in several situations. For example, reports may be issued when (i) explicitly or implicitly converting from a void pointer to a different byte ordered type; (ii) explicitly or implicitly converting to a void pointer from a different byte ordered type; (iii) implicitly converting from a void pointer to another void pointer with a different byte order; and (iv) explicitly or implicitly converting from or to a void size pointer where the underlying type has a different size (e.g., converting from a 32 bit value to a 64 bit value via a void pointer).

Embodiments may be implemented in many different system types. Referring now to FIG. 4, shown is a block diagram of a system in accordance with an embodiment of the present invention. Multiprocessor system 500 is a point-to-point interconnect system, and includes a first processor 570 and a second processor 580 coupled via a point-to-point interconnect 550. Each of processors 570 and 580 may be multicore processors, including first and second processor cores (i.e., processor cores 574a and 574b and processor cores 584a and 584b), although potentially many more cores may be present in the processors. The term â€œprocessorâ€ may refer to any device or portion of a device that processes electronic data from registers and/or memory to transform that electronic data into other electronic data that may be stored in registers and/or memory.

First processor 570 further includes a memory controller hub (MCH) 572 and point-to-point (P-P) interfaces 576 and 578. Similarly, second processor 580 includes a MCH 582 and P-P interfaces 586 and 588. MCHs 572 and 582 couple the processors to respective memories, namely a memory 532 and a memory 534, which may be portions of main memory (e.g., a dynamic random access memory (DRAM)) locally attached to the respective processors. First processor 570 and second processor 580 may be coupled to a chipset 590 via P-P interconnects 552 and 554, respectively. Chipset 590 includes P-P interfaces 594 and 598.

Furthermore, chipset 590 includes an interface 592 to couple chipset 590 with a high performance graphics engine 538, by a P-P interconnect 539. In turn, chipset 590 may be coupled to a first bus 516 via an interface 596. Various input/output (I/O) devices 514 may be coupled to first bus 516, along with a bus bridge 518, which couples first bus 516 to a second bus 520. Various devices may be coupled to second bus 520 including, for example, a keyboard/mouse 522, communication devices 526, and data storage unit 528 such as a disk drive or other mass storage device, which may include code 530, in one embodiment. Further, an audio I/O 524 may be coupled to second bus 520.

Embodiments may be implemented in code and may be stored on a storage medium having stored thereon instructions which can be used to program a system to perform the instructions. The storage medium may include, but is not limited to, any type of disk including floppy disks, optical disks, optical disks, solid state drives (SSDs), compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic random access memories (DRAMs), static random access memories (SRAMs), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.

Embodiments of the invention may be described herein with reference to data such as instructions, functions, procedures, data structures, application programs, configuration settings, code, etc. When the data is accessed by a machine, the machine may respond by performing tasks, defining abstract data types, establishing low-level hardware contexts, and/or performing other operations, as described in greater detail herein. The data may be stored in volatile and/or non-volatile data storage. For purposes of this disclosure, the terms â€œcodeâ€ or â€œprogramâ€ cover a broad range of components and constructs, including applications, drivers, processes, routines, methods, modules, and subprograms. Thus, the terms â€œcodeâ€ or â€œprogramâ€ may be used to refer to any collection of instructions which, when executed by a processing system, performs a desired operation or operations. In addition, alternative embodiments may include processes that use fewer than all of the disclosed operations, processes that use additional operations, processes that use the same operations in a different sequence, and processes in which the individual operations disclosed herein are combined, subdivided, or otherwise altered. Endian conversion is often discussed herein with regard to byteswap instructions but various embodiments are not necessarily limited to employing any specific type of instructions to perform or promote endian conversion.

While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.