分类： LINUX
2010-05-27 10:02:58
This article describers the PIC (Position Independant Code) and GOT (Global Offset Table) used in CellOS.
IntroductionSometimes, we have to write PIC (Position Independant Code). In the PIC code, we sometimes need to refer to some absolute symbols. But PIC code can not itself contain absolute virtual addresses. So GOT is used to solve this issue.
CellOS uses the same mechanism to solve the PIC code refering to absolute addresses issues. The following article is to undertand the GOT details with a "reverse engineering" way.
DetailsThe following theory section is copied from the
When the system creates a process image, the executable file portion of the process has fixed addresses and the system chooses shared object library virtual addresses to avoid conflicts with other segments in the process. To maximize text sharing, shared objects conventionally use position-independent code, in which instructions contain no absolute addresses. Shared object text segments can be loaded at various virtual addresses without having to change the segment images. Thus multiple processes can share a single shared object text segment, even if the segment reside at a different virtual address in each process.
Position-independent code relies on two techniques:
Because the PowerPC Architecture provides EA-relative branch instructions and also branch instructions using registers that hold the transfer address, compilers can satisfy the first condition easily.
A "Global Offset Table," or GOT, provides information for address calculation. Position independent object files (executable and shared object files) have a table in their data segment that holds addresses. When the system creates the memory image for an object file, the table entries are relocated to reflect the absolute virtual address as assigned for an individual process. Because data segments are private for each process, the table entries can change—unlike text segments, which multiple processes share.
Position-independent code cannot, in general, contain absolute virtual addresses. Global offset tables hold absolute addresses in private data, thus making the addresses available without compromising the position-independence and sharability of a program’s text. A program references its global offset table using position-independent addressing and extracts absolute values, thus redirecting position-independent references to absolute locations.
When the dynamic linker creates memory segments for a loadable object file, it processes the relocation entries, some of which will be of type R_PPC_GLOB_DAT, referring to the global offset table. The dynamic linker determines the associated symbol values, calculates their absolute addresses, and sets the global offset table entries to the proper values. Although the absolute addresses are unknown when the link editor builds an object file, the dynamic linker knows the addresses of all memory segments and can thus calculate the absolute addresses of the symbols contained therein.
A global offset table entry provides direct access to the absolute address of a symbol without compromising position-independence and sharability. Because the executable file and shared objects have separate global offset tables, a symbol may appear in several tables. The dynamic linker processes all the global offset table relocations before giving control to any code in the process image, thus ensuring the absolute addresses are available during execution.
The dynamic linker may choose different memory segment addresses for the same shared object in different programs; it may even choose different library addresses for different executions of the same program. Nonetheless, memory segments do not change addresses once the process image is established. As long as a process exists, its memory segments reside at fixed virtual addresses.
A global offset table’s format and interpretation are processor specific. For PowerPC, the symbol GLOBAL_OFFSET_TABLE may be used to access the table. The symbol may reside in the middle of the .got section, allowing both positive and negative "subscripts" into the array of addresses. Four words in the global offset table are reserved:
text relating to Figure 3-33, "Prologue and Epilogue Sample Code").
This allows a program, such as the dynamic linker, to find its own dynamic structure without having yet processed its relocation entries. This is especially important for the dynamic linker, because it must initialize itself without relying on other programs to relocate its memory image.
The following code defines the GOT entries;
/***************************************************************************In the cellEntry code, before it transfers to the normal C code, it calls GET_GOT.
GET_GOT /* initialize GOT access */The disasm of the above code section is :
0x000021b8 <cellosEntry+184>: bl 0x21bc <cellosEntry+188> #bl 1fEven it is not strictly related, we describe the compiler trick that is shown above:
We have seen that the GET_GOT is written like this:
#define GET_GOT \If there is no ".text 2" in the above macro, then we can imagine there is an immediate value defined just between the "bl 1f" and "1: mflr " instrcution; However, the ".text 2" seems to trigger the compiler to move the immediate value to somewhere else, not between the two instructions. Should there is no ".text 2", the immediate value were to be put in between the two intructions, thus the (0f - 1f) were to be -4;
However, with the ".text 2", the (0f - 1f) becomes 936 (in this compilation, and can vary with different compilations if you have other code added or changed), because the immediate value has been "moved" to a position higer than the CIA.
The (0f - 1f), in this case, the value 936, is an intermediate offset, at that offset (to the CIA), stores the real offset value from the centor of the GOT to CIA; In our case, the CIA for the "1: mflr " is 0x000021bc; 0x000021bc + 936 = 0x2564; check the disasm and debug the code, you will find the following:
(gdb) x/xw 0x2564 #to display the memory at 0x2564So, the "lwz ,936()" say "lwz r0,0b-1b(r14)" is to load the with a value 0x0000f468; This 0x0000f468 is the real offset from CIA to the centor of GOT; Thus the "add ,," is actually to add the CIA with the offset to the centor of GOT, which in effect is to set to "sit" in the centor of GOT;
Note that I said several times of "centor of GOT", becasue I interpret that the can be added with a 16bit "signed" offset to access the contents around ; I call the GOT anchor. This is a little bit like the SDA (Small Data Area) concept.
So, now the is set to sit in the centor of a GOT area, where it can easily used to locate the "values" around it (+/- 32KB); is not changed across the execution from now on. Let's now remember the value of , which is 0x0000f468 + 0x000021bc = 0x11624; We need to use this 0x11624 to calculate the address of the entries in the GOT.
3. How GOT is used to access the absolute symbols ?Let's find a case where the GOT is used in CellOS.
When the system is running and an interrupt happens, interrupt handling is run, where GOT is used:
/*The disasm code for the a bove code section looks like this:
00003568 <PIT>:So, we saw there is a simple usage of , that is "lwz ,-32748()", or "lwz ,GOT(transfer_to_handler)". Remember that = 0x11624, this instrcution is to load from EA = 0x11624 - 32748 = 0x9638.
So what is the value in 0x9638?
(gdb) x/xw 0x9638OK, we see something called "GOT2_TABLE", seems familar? Yes, GOT! Looking back in this article, there is (yes, I copied it twice, becasue the space is for free :-))
/*The GOT_ENTRY is to define an entry "around" the centor of GOT (the GOT anchor).
#define GOT_ENTRY(NAME) .L_ ## NAME = . - .LCTOC1 ; .long NAMEThe actual GOT table looks like this:
00009600 <_GOT2_TABLE_>:So, at "9638: 00 00 22 9c .long 0x229c", there stores a value 0x229c;
(gdb) x/xw 0x229cRight, that is what we want! The address of the function transfer_to_handler is stored in the GOT entry.
So now we have a very clear understanding to the GOT. It is actually a "jumping table", through which an indirect addressing to the absolute addresses are performed. This technic is is mostly used for operating systems to load exe images using shared objects. For CellOS, derived from u-boot, it simply severs as a way to locate some absolute symbols.
4. Note for the ones curious with the question : where GOT2_TABLE comes from?In the linker script,there is a section:
.reloc :You should be noted that in the first entry of "GOT2_TABLE", the entry specify the address of the GOT2_TABLE itself (0x9600).
00009600 <_GOT2_TABLE_>: