$ objdump -h Image
Image: file format elf64-x86-64
Sections:
Idx Name Size VMA LMA File
off Algn
0 .text 0019d870 ffffffff90008000 0000000010008000
00000120 2**5
CONTENTS, ALLOC, LOAD, CODE
1 .wrs_build_vars 00000150 ffffffff901a5870 00000000101a5870
0019d990 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .data 0000db50 ffffffff901a59c0 00000000101a59c0
0019db00 2**6
CONTENTS, ALLOC, LOAD, DATA
3 .bss 01016e40 ffffffff901b3520 00000000101b3520
001ab660 2**5
ALLOC
$ objdump -f Image
Image: file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000012:
EXEC_P, HAS_SYMS
start address 0xffffffff90008000
I tried to load it via GRUB2, but unfortunately it displays 'invalid
entry point for ELF64'. The problem is that for 64-bit ELF images the
multiboot_elfxx.c library still requires 32-bit virtual address:
#ifdef MULTIBOOT_LOAD_ELF64
# if defined( __mips)
/* We still in 32-bit mode. */
if (ehdr->e_entry < 0xffffffff80000000ULL)
return grub_error (GRUB_ERR_BAD_OS, "invalid entry point for ELF64");
# else
/* We still in 32-bit mode. */
if (ehdr->e_entry > 0xffffffff)
return grub_error (GRUB_ERR_BAD_OS, "invalid entry point for ELF64");
# endif
#endif
Could you tell me why this assumption is required? The virtual address
(e_entry is virtual following ELF specification) is related to the image
itself, how it setup MMU, not the loader (GRUB2). GRUB2 should check
only if the physical location of loaded image is in 32-bit physical
memory.
Besides if we skip thich e_entry check, the image is properly loaded,
because grub_multiboot_payload_eip is properly computed few lines below.
grub_multiboot_payload_eip = (ehdr->e_entry - phdr(i)->p_vaddr)
+ phdr(i)->p_paddr;
Could you tell me why GRUB2 checks for 64-bit images this e_entry
virtual address (which can be everywhere in the 64-bit address space)
and requires it to be 32-bit address space only?
Regards
Pawel Wojtalczyk
_______________________________________________
Grub-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/grub-devel