Lines Matching refs:in

19 development environment contained in this directory.  The second part
96 It is necessary to edit the Makefile in the directory containing this
102 If you're working in a cross-development environment, be sure to set
110 To build the sample EFI applications provided in subdirectory "apps",
111 simply invoke "make" in the toplevel directory (the directory
128 Suppose you have your own EFI application in a file called
130 environment, simply add "myefiapp.efi" to macro TARGETS in
131 apps/Makefile.  Once this is done, invoke "make" in the top level
132 directory.  This should result in EFI application apps/myefiapp.efi,
136 described in Intel's EFI documentation, except for two differences:
144    instead of just L"Sample String".  The W2U() macro is defined in
147    store the result in a programmer-supplied buffer.
165 object file format with an MS-DOS2.0 compatible header slapped on in
166 front of it.  The "32" in PE32+ stands for 32 bits, meaning that PE32
167 is a 32-bit object file format.  The plus in "PE32+" indicates that
168 this format has been hacked to allow loading a 4GB binary anywhere in
200 	Since EFI binaries are executed in physical mode, EFI cannot
216 	4 bytes in size.  The encoding used for such characters is
227 in gnuefi/elf_$(ARCH)_efi.lds where $(ARCH) is the target architecture
231 greater number of sections that are typically present in ELF object files.
236 	section in order to build a shared object file; the section is
253 	The reason read-only data is placed here instead of the in
256 	EFI binaries execute in physical mode, differences in page
259 	The reason the uninitialized data is placed in this section is
274    in this fashion, so with some care it should be possible to build
276    to be addressable in this fashion, grep the assembly files in
286    cannot be placed inside .data because some tools in the GNU
289  o Some sections in the ELF binary intentionally get dropped when
292    be _wrong_ to include these sections in the EFI binary because it
293    would result in .reloc and .plabel being relocated twice (once by
296    mentioned with the -j option in the final "objcopy" command are
297    retained in the EFI binary (see Make.rules).
309 The approach to building relocatable binaries in the GNU EFI build
315      applying the dynamic relocations that may be present in the
321 version can be found in gnuefi/reloc_ia32.c, the x86_64 version
322 can be found in gnuefi/reloc_x86_64.c and the IA-64 version can be
323 found in gnuefi/reloc_ia64.S.
329 dynamic relocation information, which can be found in the DT_REL,
331 DT_RELASZ, and DT_RELAENT in the case of rela relocations, as is the
340 dynamic symbol table.  This is why the .dynsym section is included in
348 MAX_FUNCTION_DESCRIPTORS in gnuefi/reloc_ia64.S should be increased
366 in gnuefi/crt0-efi-ia64.S crafts one manually by with the code:
373 this places the procedure label for entry point _start in a section
377 this.  Thus, in addition to manually crafting the function descriptor,
383 A final question may be why .plabel and .reloc need to go in their own
386 placing them in these sections, the relocations end up in sections
388 out in the filter script.  Also, the ".reloc" section needs to be in
390 create the correct directory entries in the PE32+ binary.