search for: elf64_addr

...or should it be treated as target specific? My contention is that it should be treated as an alternative generic format handled recognized and handled in the ELF class objects above the target specific level. Most architectures have the following 64 bit relocation record format: typedef struct { Elf64_Addr r_offset; /* Address of reference */ Elf64_Xword r_info; /* Symbol index and type of relocation */ } Elf64_Rel; typedef struct { Elf64_Addr r_offset; Elf64_Xword r_info; Elf64_Sxword r_addend; } Elf64_Rela; Whereas N64 has the following format: typedef struct { Elf64_Addr r_offse...

...st_value; Elf32_Word st_size; unsigned char st_info; unsigned char st_other; Elf32_Half st_shndx; } Elf32_Sym; typedef struct { Elf64_Word st_name; unsigned char st_info; unsigned char st_other; Elf64_Half st_shndx; Elf64_Addr st_value; Elf64_Xword st_size; } Elf64_Sym; The st_size and st_value fields could be used to represent attribute information about a given symbol: * The st_size field can be split into an attribute ID and a symbol index for the symbol that the attribute applies to * attr...

...@@ SECTIONS __bss_dwords = (__bss_len + 3) >> 2; . = ALIGN(128); - + /* Very large objects which don't need to be zeroed */ .hugebss : { diff --git a/efi/wrapper.c b/efi/wrapper.c index 4839e52..1988124 100644 --- a/efi/wrapper.c +++ b/efi/wrapper.c @@ -35,7 +35,7 @@ typedef Elf64_Addr Elf_Addr; #endif /* - * 'so_size' is the file size of the ELF shared object. + * 'so_memsz' is the size of the ELF shared object once loaded. * 'data_size' is the size of initialised data in the shared object. * 'class' dictates how the header is written *...

...@@ SECTIONS __bss_dwords = (__bss_len + 3) >> 2; . = ALIGN(128); - + /* Very large objects which don't need to be zeroed */ .hugebss : { diff --git a/efi/wrapper.c b/efi/wrapper.c index 9652368..a5247ae 100644 --- a/efi/wrapper.c +++ b/efi/wrapper.c @@ -35,7 +35,7 @@ typedef Elf64_Addr Elf_Addr; #endif /* - * 'so_size' is the file size of the ELF shared object. + * 'so_memsz' is the size of the ELF shared object once loaded. * 'data_size' is the size of initialised data in the shared object. * 'class' dictates how the header is written *...

...har st_other; > > Elf32_Half st_shndx; > > } Elf32_Sym; > > > > typedef struct { > > Elf64_Word st_name; > > unsigned char st_info; > > unsigned char st_other; > > Elf64_Half st_shndx; > > Elf64_Addr st_value; > > Elf64_Xword st_size; > > } Elf64_Sym; > > > > The st_size and st_value fields could be used to represent attribute information about a given symbol: > > > > The st_size field can be split into an attribute ID and a symbol index for the...

The PE headers of the generated efi file were quite buggy. And since OVMF perform a few consistency checks, syslinux was unable to run on it. I don't pretend to have a thorough understanding of the PE+ headers, some bugs may remain. :) Celelibi (4): efi: Fix PE header field rva_and_sizes_nr efi: Location, size and alignment of .text section efi: Useless relocations in PE file efi: PE

...; > } Elf32_Sym; > > > > typedef struct { > > Elf64_Word st_name; > > unsigned char st_info; > > unsigned char st_other; > > Elf64_Half st_shndx; > > Elf64_Addr st_value; > > Elf64_Xword st_size; > > } Elf64_Sym; > > > > The st_size and st_value fields could be used to represent attribute information about a given symbol: > > > > The st_size field can be split...

...red in the image headers */ #define PT_NULL 0 @@ -124,6 +126,7 @@ typedef __s64 Elf64_Sxword; #define ELF64_ST_BIND(x) ELF_ST_BIND(x) #define ELF64_ST_TYPE(x) ELF_ST_TYPE(x) +#ifndef __ASSEMBLY__ struct elf32_dyn { Elf32_Sword d_tag; union{ @@ -139,6 +142,7 @@ struct elf64_dyn { Elf64_Addr d_ptr; } d_un; }; +#endif /* __ASSEMBLY__ */ /* The following are used with relocations */ #define ELF32_R_SYM(x) ((x) >> 8) @@ -147,6 +151,7 @@ struct elf64_dyn { #define ELF64_R_SYM(i) ((i) >> 32) #define ELF64_R_TYPE(i) ((i) & 0xffffffff) +#ifndef __ASSEMBLY__ st...

...red in the image headers */ #define PT_NULL 0 @@ -124,6 +126,7 @@ typedef __s64 Elf64_Sxword; #define ELF64_ST_BIND(x) ELF_ST_BIND(x) #define ELF64_ST_TYPE(x) ELF_ST_TYPE(x) +#ifndef __ASSEMBLY__ struct elf32_dyn { Elf32_Sword d_tag; union{ @@ -139,6 +142,7 @@ struct elf64_dyn { Elf64_Addr d_ptr; } d_un; }; +#endif /* __ASSEMBLY__ */ /* The following are used with relocations */ #define ELF32_R_SYM(x) ((x) >> 8) @@ -147,6 +151,7 @@ struct elf64_dyn { #define ELF64_R_SYM(i) ((i) >> 32) #define ELF64_R_TYPE(i) ((i) & 0xffffffff) +#ifndef __ASSEMBLY__ st...

...in the image headers */ #define PT_NULL 0 @@ -123,6 +125,7 @@ typedef __s64 Elf64_Sxword; #define ELF64_ST_BIND(x) ELF_ST_BIND(x) #define ELF64_ST_TYPE(x) ELF_ST_TYPE(x) +#ifndef __ASSEMBLY__ typedef struct dynamic{ Elf32_Sword d_tag; union{ @@ -138,6 +141,7 @@ typedef struct { Elf64_Addr d_ptr; } d_un; } Elf64_Dyn; +#endif /* __ASSEMBLY__ */ /* The following are used with relocations */ #define ELF32_R_SYM(x) ((x) >> 8) @@ -146,6 +150,7 @@ typedef struct { #define ELF64_R_SYM(i) ((i) >> 32) #define ELF64_R_TYPE(i) ((i) & 0xffffffff) +#ifndef __ASSEMB...

...in the image headers */ #define PT_NULL 0 @@ -123,6 +125,7 @@ typedef __s64 Elf64_Sxword; #define ELF64_ST_BIND(x) ELF_ST_BIND(x) #define ELF64_ST_TYPE(x) ELF_ST_TYPE(x) +#ifndef __ASSEMBLY__ typedef struct dynamic{ Elf32_Sword d_tag; union{ @@ -138,6 +141,7 @@ typedef struct { Elf64_Addr d_ptr; } d_un; } Elf64_Dyn; +#endif /* __ASSEMBLY__ */ /* The following are used with relocations */ #define ELF32_R_SYM(x) ((x) >> 8) @@ -146,6 +150,7 @@ typedef struct { #define ELF64_R_SYM(i) ((i) >> 32) #define ELF64_R_TYPE(i) ((i) & 0xffffffff) +#ifndef __ASSEMB...

...> > Elf64_Word st_name; > > > > > > unsigned char st_info; > > > > > > unsigned char st_other; > > > > > > Elf64_Half st_shndx; > > > > > > Elf64_Addr st_value; > > > > > > Elf64_Xword st_size; > > > > > > } Elf64_Sym; > > > > > > > > > > > > The st_size and st_value fields could be used to represent attribute information about a...

...> > Elf64_Word st_name; > > > > > > unsigned char st_info; > > > > > > unsigned char st_other; > > > > > > Elf64_Half st_shndx; > > > > > > Elf64_Addr st_value; > > > > > > Elf64_Xword st_size; > > > > > > } Elf64_Sym; > > > > > > > > > > > > The st_size and st_value fields could be used to represent attribute information about a...

This series: 1. Updates the boot protocol to version 2.07 2. Clean up the existing build process, to get rid of tools/build and make the linker do more heavy lifting 3. Make the bzImage payload an ELF file. The bootloader can extract this as a naked ELF file by skipping over boot_params.setup_sects worth of 16-bit setup code. 4. Update the boot_params to 2.07, and update the

This series: 1. Updates the boot protocol to version 2.07 2. Clean up the existing build process, to get rid of tools/build and make the linker do more heavy lifting 3. Make the bzImage payload an ELF file. The bootloader can extract this as a naked ELF file by skipping over boot_params.setup_sects worth of 16-bit setup code. 4. Update the boot_params to 2.07, and update the

...; >> > > > unsigned char st_info; >> > > > >> > > > unsigned char st_other; >> > > > >> > > > Elf64_Half st_shndx; >> > > > >> > > > Elf64_Addr st_value; >> > > > >> > > > Elf64_Xword st_size; >> > > > >> > > > } Elf64_Sym; >> > > > >> > > > >> > > > >> > > > The st_size and s...

...name; > > > > > > > > unsigned char st_info; > > > > > > > > unsigned char st_other; > > > > > > > > Elf64_Half st_shndx; > > > > > > > > Elf64_Addr st_value; > > > > > > > > Elf64_Xword st_size; > > > > > > > > } Elf64_Sym; > > > > > > > > > > > > > > > > The st_size and st_value fields could be used to...

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some