Baruch: Split into two sections

2013-08-19T04:47:00Z

Split into two sections

← Older revision		Revision as of 04:47, 19 August 2013
Line 1:		Line 1:
	'''Note:''' macros and data structures that are mentioned below refer to uClibc source code, unless otherwise stated.		'''Note:''' macros and data structures that are mentioned below refer to uClibc source code, unless otherwise stated.

	~~The~~ Global Offset Table (GOT~~; resides in the <tt>.got</tt> section)~~ has only one pointer entry. The link editor keeps in this GOT entry a pointer to the <tt>.dynamic</tt> section. At run-time the dynamic linker sets the same entry to point to the _dl_linux_resolve() routine. This pointer is later replicated to the beginning of each PLT chunk using the <tt>R_XTENSA_RTLD</tt> type 1 relocation (see below).		== Xtensa Global Offset Table ==

			The GOT has only one pointer entry. The link editor keeps in this GOT entry a pointer to the <tt>.dynamic</tt> section. At run-time the dynamic linker sets the same entry to point to the _dl_linux_resolve() routine. This pointer is later replicated to the beginning of each PLT chunk using the <tt>R_XTENSA_RTLD</tt> type 1 relocation (see below).

	The "real" GOT is pointed at from and array of (offset, length) pairs (<tt>xtensa_got_location</tt> data type) at the <tt>.got.loc</tt> section. The offset and size of this array are kept in xtensa specific <tt>.dynamic</tt> section tags named <tt>DT_XTENSA_GOT_LOC_OFF</tt> and <tt>DT_XTENSA_GOT_LOC_SZ</tt>, respectively. This "real" GOT is part of <tt>.text</tt> section, and as such is flagged for read and execute only. However, xtensa specific macros (<tt>PERFORM_BOOTSTRAP_GOT</tt> at start-up time, <tt>INIT_GOT</tt> at run-time load [<tt>elf_machine_runtime_setup()</tt> in glibc]) use <tt>_dl_mprotect()</tt> to change the protection bits on the <tt>.text</tt> pages pointed from the <tt>.got.loc</tt> section, and allow write access.		The "real" GOT is pointed at from and array of (offset, length) pairs (<tt>xtensa_got_location</tt> data type) at the <tt>.got.loc</tt> section. The offset and size of this array are kept in xtensa specific <tt>.dynamic</tt> section tags named <tt>DT_XTENSA_GOT_LOC_OFF</tt> and <tt>DT_XTENSA_GOT_LOC_SZ</tt>, respectively. This "real" GOT is part of <tt>.text</tt> section, and as such is flagged for read and execute only. However, xtensa specific macros (<tt>PERFORM_BOOTSTRAP_GOT</tt> at start-up time, <tt>INIT_GOT</tt> at run-time load [<tt>elf_machine_runtime_setup()</tt> in glibc]) use <tt>_dl_mprotect()</tt> to change the protection bits on the <tt>.text</tt> pages pointed from the <tt>.got.loc</tt> section, and allow write access.
Line 10:		Line 12:
	# The <tt>.got.loc</tt> section contains a short array of GOT locations at the beginning, and is mostly filled with zeros, why?		# The <tt>.got.loc</tt> section contains a short array of GOT locations at the beginning, and is mostly filled with zeros, why?
	# Are <tt>.xt.lit</tt> and <tt>.xt.prop</tt> really needed at run-time?		# Are <tt>.xt.lit</tt> and <tt>.xt.prop</tt> really needed at run-time?

			== Run-Time Relocations ==

	Xtensa run-time relocations as implemented in <tt>_dl_do_reloc()</tt>:		Xtensa run-time relocations as implemented in <tt>_dl_do_reloc()</tt>:

Baruch: New page: '''Note:''' macros and data structures that are mentioned below refer to uClibc source code, unless otherwise stated. The Global Offset Table (GOT; resides in the `.got` section) h...

2013-08-18T15:07:56Z

New page: '''Note:''' macros and data structures that are mentioned below refer to uClibc source code, unless otherwise stated. The Global Offset Table (GOT; resides in the <tt>.got</tt> section) h...

New page

'''Note:''' macros and data structures that are mentioned below refer to uClibc source code, unless otherwise stated.

The Global Offset Table (GOT; resides in the <tt>.got</tt> section) has only one pointer entry. The link editor keeps in this GOT entry a pointer to the <tt>.dynamic</tt> section. At run-time the dynamic linker sets the same entry to point to the _dl_linux_resolve() routine. This pointer is later replicated to the beginning of each PLT chunk using the <tt>R_XTENSA_RTLD</tt> type 1 relocation (see below).

The "real" GOT is pointed at from and array of (offset, length) pairs (<tt>xtensa_got_location</tt> data type) at the <tt>.got.loc</tt> section. The offset and size of this array are kept in xtensa specific <tt>.dynamic</tt> section tags named <tt>DT_XTENSA_GOT_LOC_OFF</tt> and <tt>DT_XTENSA_GOT_LOC_SZ</tt>, respectively. This "real" GOT is part of <tt>.text</tt> section, and as such is flagged for read and execute only. However, xtensa specific macros (<tt>PERFORM_BOOTSTRAP_GOT</tt> at start-up time, <tt>INIT_GOT</tt> at run-time load [<tt>elf_machine_runtime_setup()</tt> in glibc]) use <tt>_dl_mprotect()</tt> to change the protection bits on the <tt>.text</tt> pages pointed from the <tt>.got.loc</tt> section, and allow write access.

Open questions:

# The sections <tt>.got.loc</tt> and <tt>.xt.lit</tt> look identical, why are both needed?
# The <tt>.got.loc</tt> section contains a short array of GOT locations at the beginning, and is mostly filled with zeros, why?
# Are <tt>.xt.lit</tt> and <tt>.xt.prop</tt> really needed at run-time?

Xtensa run-time relocations as implemented in <tt>_dl_do_reloc()</tt>:

; <tt>R_XTENSA_GLOB_DAT, R_XTENSA_JMP_SLOT</tt> : Relocate to symbol address + addend. In terms of the Intel psABI the calculation is 'S + A'.

; <tt>R_XTENSA_RTLD</tt> : This includes two relocation types selected by the addend field. Type 1 inserts a pointer to the <tt>_dl_linux_resolve()</tt> routine (taken by the dynamic linker from the first (and only) entry of the <tt>.got</tt> section). Type 2 inserts a pointer to the per-module '<tt>struct elf_resolve</tt>' data structure. According to the binutils <tt>elf_xtensa_finish_dynamic_sections()</tt> routine, this relocation is emitted at the beginning of each PLT "chunk". Each Chunk holds up to 254 PLT entries. The <tt>_dl_linux_resolve()</tt> pointer, and the link map pointer (struct elf_resolve) are the first two parameters of the initial PLT routine (<tt>elf_xtensa_le_plt_entry[]</tt>).

; <tt>R_XTENSA_RELATIVE</tt> : Used to adjust internal pointers in the "real" GOT according to the current load address, mainly in shared libraries.

ELF Relocation Notes - Revision history

Baruch: Split into two sections

Baruch: New page: '''Note:''' macros and data structures that are mentioned below refer to uClibc source code, unless otherwise stated. The Global Offset Table (GOT; resides in the .got section) h...

Baruch: New page: '''Note:''' macros and data structures that are mentioned below refer to uClibc source code, unless otherwise stated. The Global Offset Table (GOT; resides in the `.got` section) h...