Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers
Hi On Mon, Jan 15, 2018 at 7:41 AM, Kevin Wolfwrote: > Am 13.10.2017 um 01:54 hat Anatol Pomozov geschrieben: >> Multiboot may load section headers and all sections (even those that are >> not part of any segment) to target memory. >> >> Tested with an ELF application that uses data from strings table >> section. >> >> Signed-off-by: Anatol Pomozov >> --- >> hw/core/loader.c | 8 +-- >> hw/i386/multiboot.c | 83 +--- >> hw/s390x/ipl.c | 2 +- >> include/hw/elf_ops.h | 107 >> ++- >> include/hw/loader.h | 11 +++- >> tests/multiboot/Makefile | 8 ++- >> tests/multiboot/generate_sections_out.py | 33 ++ >> tests/multiboot/modules.out | 22 +++ >> tests/multiboot/run_test.sh | 6 +- >> tests/multiboot/sections.c | 55 >> tests/multiboot/start.S | 2 +- >> 11 files changed, 276 insertions(+), 61 deletions(-) >> create mode 100755 tests/multiboot/generate_sections_out.py >> create mode 100644 tests/multiboot/sections.c >> >> diff --git a/hw/core/loader.c b/hw/core/loader.c >> index 4593061445..a8787f7685 100644 >> --- a/hw/core/loader.c >> +++ b/hw/core/loader.c >> @@ -439,7 +439,7 @@ int load_elf_as(const char *filename, >> { >> return load_elf_ram(filename, translate_fn, translate_opaque, >> pentry, lowaddr, highaddr, big_endian, elf_machine, >> -clear_lsb, data_swab, as, true); >> +clear_lsb, data_swab, as, true, NULL); >> } >> >> /* return < 0 if error, otherwise the number of bytes loaded in memory */ >> @@ -448,7 +448,7 @@ int load_elf_ram(const char *filename, >> void *translate_opaque, uint64_t *pentry, uint64_t >> *lowaddr, >> uint64_t *highaddr, int big_endian, int elf_machine, >> int clear_lsb, int data_swab, AddressSpace *as, >> - bool load_rom) >> + bool load_rom, SectionsData *sections) >> { >> int fd, data_order, target_data_order, must_swab, ret = ELF_LOAD_FAILED; >> uint8_t e_ident[EI_NIDENT]; >> @@ -488,11 +488,11 @@ int load_elf_ram(const char *filename, >> if (e_ident[EI_CLASS] == ELFCLASS64) { >> ret = load_elf64(filename, fd, translate_fn, translate_opaque, >> must_swab, >> pentry, lowaddr, highaddr, elf_machine, clear_lsb, >> - data_swab, as, load_rom); >> + data_swab, as, load_rom, sections); >> } else { >> ret = load_elf32(filename, fd, translate_fn, translate_opaque, >> must_swab, >> pentry, lowaddr, highaddr, elf_machine, clear_lsb, >> - data_swab, as, load_rom); >> + data_swab, as, load_rom, sections); >> } >> >> fail: >> diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c >> index 7dacd6d827..841d05160a 100644 >> --- a/hw/i386/multiboot.c >> +++ b/hw/i386/multiboot.c >> @@ -125,7 +125,7 @@ int load_multiboot(FWCfgState *fw_cfg, >> { >> int i; >> bool is_multiboot = false; >> -uint32_t flags = 0; >> +uint32_t flags = 0, bootinfo_flags = 0; >> uint32_t mh_entry_addr; >> uint32_t mh_load_addr; >> uint32_t mb_kernel_size; >> @@ -134,6 +134,7 @@ int load_multiboot(FWCfgState *fw_cfg, >> uint8_t *mb_bootinfo_data; >> uint32_t cmdline_len; >> struct multiboot_header *multiboot_header; >> +SectionsData sections; >> >> /* Ok, let's see if it is a multiboot image. >> The header is 12x32bit long, so the latest entry may be 8192 - 48. */ >> @@ -161,37 +162,8 @@ int load_multiboot(FWCfgState *fw_cfg, >> if (flags & MULTIBOOT_VIDEO_MODE) { >> fprintf(stderr, "qemu: multiboot knows VBE. we don't.\n"); >> } >> -if (!(flags & MULTIBOOT_AOUT_KLUDGE)) { >> -uint64_t elf_entry; >> -uint64_t elf_low, elf_high; >> -int kernel_size; >> -fclose(f); >> >> -if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) { >> -fprintf(stderr, "Cannot load x86-64 image, give a 32bit >> one.\n"); >> -exit(1); >> -} > > I'm not sure why you're reversing the condition and moving this branch > down, but in the code movements the EM_X86_64 check got lost. Please > keep it, we don't support 64 bit ELFs at the moment. If you want to > change this, it should be a separate patch. Ok I moved it to a separate patch. > >> -kernel_size = load_elf(kernel_filename, NULL, NULL, _entry, >> - _low, _high, 0, EM_NONE, >> - 0, 0); >> -if (kernel_size < 0) { >> -fprintf(stderr, "Error while loading elf
Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers
Am 13.10.2017 um 01:54 hat Anatol Pomozov geschrieben: > Multiboot may load section headers and all sections (even those that are > not part of any segment) to target memory. > > Tested with an ELF application that uses data from strings table > section. > > Signed-off-by: Anatol Pomozov> --- > hw/core/loader.c | 8 +-- > hw/i386/multiboot.c | 83 +--- > hw/s390x/ipl.c | 2 +- > include/hw/elf_ops.h | 107 > ++- > include/hw/loader.h | 11 +++- > tests/multiboot/Makefile | 8 ++- > tests/multiboot/generate_sections_out.py | 33 ++ > tests/multiboot/modules.out | 22 +++ > tests/multiboot/run_test.sh | 6 +- > tests/multiboot/sections.c | 55 > tests/multiboot/start.S | 2 +- > 11 files changed, 276 insertions(+), 61 deletions(-) > create mode 100755 tests/multiboot/generate_sections_out.py > create mode 100644 tests/multiboot/sections.c > > diff --git a/hw/core/loader.c b/hw/core/loader.c > index 4593061445..a8787f7685 100644 > --- a/hw/core/loader.c > +++ b/hw/core/loader.c > @@ -439,7 +439,7 @@ int load_elf_as(const char *filename, > { > return load_elf_ram(filename, translate_fn, translate_opaque, > pentry, lowaddr, highaddr, big_endian, elf_machine, > -clear_lsb, data_swab, as, true); > +clear_lsb, data_swab, as, true, NULL); > } > > /* return < 0 if error, otherwise the number of bytes loaded in memory */ > @@ -448,7 +448,7 @@ int load_elf_ram(const char *filename, > void *translate_opaque, uint64_t *pentry, uint64_t *lowaddr, > uint64_t *highaddr, int big_endian, int elf_machine, > int clear_lsb, int data_swab, AddressSpace *as, > - bool load_rom) > + bool load_rom, SectionsData *sections) > { > int fd, data_order, target_data_order, must_swab, ret = ELF_LOAD_FAILED; > uint8_t e_ident[EI_NIDENT]; > @@ -488,11 +488,11 @@ int load_elf_ram(const char *filename, > if (e_ident[EI_CLASS] == ELFCLASS64) { > ret = load_elf64(filename, fd, translate_fn, translate_opaque, > must_swab, > pentry, lowaddr, highaddr, elf_machine, clear_lsb, > - data_swab, as, load_rom); > + data_swab, as, load_rom, sections); > } else { > ret = load_elf32(filename, fd, translate_fn, translate_opaque, > must_swab, > pentry, lowaddr, highaddr, elf_machine, clear_lsb, > - data_swab, as, load_rom); > + data_swab, as, load_rom, sections); > } > > fail: > diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c > index 7dacd6d827..841d05160a 100644 > --- a/hw/i386/multiboot.c > +++ b/hw/i386/multiboot.c > @@ -125,7 +125,7 @@ int load_multiboot(FWCfgState *fw_cfg, > { > int i; > bool is_multiboot = false; > -uint32_t flags = 0; > +uint32_t flags = 0, bootinfo_flags = 0; > uint32_t mh_entry_addr; > uint32_t mh_load_addr; > uint32_t mb_kernel_size; > @@ -134,6 +134,7 @@ int load_multiboot(FWCfgState *fw_cfg, > uint8_t *mb_bootinfo_data; > uint32_t cmdline_len; > struct multiboot_header *multiboot_header; > +SectionsData sections; > > /* Ok, let's see if it is a multiboot image. > The header is 12x32bit long, so the latest entry may be 8192 - 48. */ > @@ -161,37 +162,8 @@ int load_multiboot(FWCfgState *fw_cfg, > if (flags & MULTIBOOT_VIDEO_MODE) { > fprintf(stderr, "qemu: multiboot knows VBE. we don't.\n"); > } > -if (!(flags & MULTIBOOT_AOUT_KLUDGE)) { > -uint64_t elf_entry; > -uint64_t elf_low, elf_high; > -int kernel_size; > -fclose(f); > > -if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) { > -fprintf(stderr, "Cannot load x86-64 image, give a 32bit one.\n"); > -exit(1); > -} I'm not sure why you're reversing the condition and moving this branch down, but in the code movements the EM_X86_64 check got lost. Please keep it, we don't support 64 bit ELFs at the moment. If you want to change this, it should be a separate patch. > -kernel_size = load_elf(kernel_filename, NULL, NULL, _entry, > - _low, _high, 0, EM_NONE, > - 0, 0); > -if (kernel_size < 0) { > -fprintf(stderr, "Error while loading elf kernel\n"); > -exit(1); > -} > -mh_load_addr = elf_low; > -mb_kernel_size = elf_high - elf_low; > -mh_entry_addr = elf_entry; > - > -mbs.mb_buf = g_malloc(mb_kernel_size); >
Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers
Am 17.11.2017 um 22:33 hat Anatol Pomozov geschrieben: > On Tue, Oct 31, 2017 at 11:38 AM, Anatol Pomozov >wrote: > > Hi > > > > On Thu, Oct 19, 2017 at 2:36 AM, Kevin Wolf wrote: > >> Am 18.10.2017 um 19:22 hat Anatol Pomozov geschrieben: > >>> Hello qemu-devs, > >>> > >>> This patchset has been posted a while ago. I would like to move > >>> forward with it and look at the next task (e.g. multiboot2 support in > >>> QEMU). Who is the multiboot code maintainer who can help to review > >>> this patchset and give go/no-go answer? > >> > >> I think that's exactly your problem, there is nobody who feels > >> responsible for Multiboot support. Officially, it is part of the PC/x86 > >> subsystems: > > > > In this case I would like to become the official Qemu/Multiboot > > maintainer. I do development related to x86 osdev and actively use > > qemu for my projects. I am interested in having a feature-rich and > > robust Multiboot implementation. > > It is very unfortunate to see lack of interest in improving > qemu/multiboot functionality. I guess my best option for now is to > avoid using qemu multiboot implementation and use grub instead. Let's wait until 2.11 is out and we're out of freeze, and then I think your best bet is to just prepare a pull request that adds you to MAINTAINERS and applies the patches you created so far. Peter, does this sound right? Kevin
Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers
Hello On Tue, Oct 31, 2017 at 11:38 AM, Anatol Pomozovwrote: > Hi > > On Thu, Oct 19, 2017 at 2:36 AM, Kevin Wolf wrote: >> Am 18.10.2017 um 19:22 hat Anatol Pomozov geschrieben: >>> Hello qemu-devs, >>> >>> This patchset has been posted a while ago. I would like to move >>> forward with it and look at the next task (e.g. multiboot2 support in >>> QEMU). Who is the multiboot code maintainer who can help to review >>> this patchset and give go/no-go answer? >> >> I think that's exactly your problem, there is nobody who feels >> responsible for Multiboot support. Officially, it is part of the PC/x86 >> subsystems: > > In this case I would like to become the official Qemu/Multiboot > maintainer. I do development related to x86 osdev and actively use > qemu for my projects. I am interested in having a feature-rich and > robust Multiboot implementation. It is very unfortunate to see lack of interest in improving qemu/multiboot functionality. I guess my best option for now is to avoid using qemu multiboot implementation and use grub instead.
Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers
Hi On Thu, Oct 19, 2017 at 2:36 AM, Kevin Wolfwrote: > Am 18.10.2017 um 19:22 hat Anatol Pomozov geschrieben: >> Hello qemu-devs, >> >> This patchset has been posted a while ago. I would like to move >> forward with it and look at the next task (e.g. multiboot2 support in >> QEMU). Who is the multiboot code maintainer who can help to review >> this patchset and give go/no-go answer? > > I think that's exactly your problem, there is nobody who feels > responsible for Multiboot support. Officially, it is part of the PC/x86 > subsystems: In this case I would like to become the official Qemu/Multiboot maintainer. I do development related to x86 osdev and actively use qemu for my projects. I am interested in having a feature-rich and robust Multiboot implementation. In mid term I see several tasks for me: - finish and merge my cleanup + MULTIBOOT_INFO_ELF_SHDR patch series - add Multiboot2 support - (optional) look at MIPS support for Multiboot. I do not have/use MIPS but it is beneficial to add multiplatform support to Multiboot - reviewing incoming patches A bit about me. My name is Anatol Pomozov and at my spare time I participate at several open sources projects. I am an Arch developer since 2013 where I maintain a bunch of packages (including Arch qemu package [1]). I have ~40 patches in the Linux kernel tree, where the biggest contribution is a driver for audio codec NAU8825. I contributed a lot of small patches to numerous projects (compilers, toolchains, ...) [1] https://www.archlinux.org/packages/extra/i686/qemu/
Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers
Am 18.10.2017 um 19:22 hat Anatol Pomozov geschrieben: > Hello qemu-devs, > > This patchset has been posted a while ago. I would like to move > forward with it and look at the next task (e.g. multiboot2 support in > QEMU). Who is the multiboot code maintainer who can help to review > this patchset and give go/no-go answer? I think that's exactly your problem, there is nobody who feels responsible for Multiboot support. Officially, it is part of the PC/x86 subsystems: $ scripts/get_maintainer.pl -f hw/i386/multiboot.c "Michael S. Tsirkin"(supporter:PC) Paolo Bonzini (maintainer:X86) Richard Henderson (maintainer:X86) Eduardo Habkost (maintainer:X86) qemu-devel@nongnu.org (open list:All patches CC here) I'm not sure if any of them know much about Multiboot. Myself, I am personally interested in having Multiboot support, which is why I've even commented on your patches, but I'm not the maintainer. The last few Multiboot patches seem to have been merged by Paolo. Kevin
Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers
Hello qemu-devs, This patchset has been posted a while ago. I would like to move forward with it and look at the next task (e.g. multiboot2 support in QEMU). Who is the multiboot code maintainer who can help to review this patchset and give go/no-go answer? On Thu, Oct 12, 2017 at 4:54 PM, Anatol Pomozovwrote: > Multiboot may load section headers and all sections (even those that are > not part of any segment) to target memory. > > Tested with an ELF application that uses data from strings table > section. > > Signed-off-by: Anatol Pomozov > --- > hw/core/loader.c | 8 +-- > hw/i386/multiboot.c | 83 +--- > hw/s390x/ipl.c | 2 +- > include/hw/elf_ops.h | 107 > ++- > include/hw/loader.h | 11 +++- > tests/multiboot/Makefile | 8 ++- > tests/multiboot/generate_sections_out.py | 33 ++ > tests/multiboot/modules.out | 22 +++ > tests/multiboot/run_test.sh | 6 +- > tests/multiboot/sections.c | 55 > tests/multiboot/start.S | 2 +- > 11 files changed, 276 insertions(+), 61 deletions(-) > create mode 100755 tests/multiboot/generate_sections_out.py > create mode 100644 tests/multiboot/sections.c > > diff --git a/hw/core/loader.c b/hw/core/loader.c > index 4593061445..a8787f7685 100644 > --- a/hw/core/loader.c > +++ b/hw/core/loader.c > @@ -439,7 +439,7 @@ int load_elf_as(const char *filename, > { > return load_elf_ram(filename, translate_fn, translate_opaque, > pentry, lowaddr, highaddr, big_endian, elf_machine, > -clear_lsb, data_swab, as, true); > +clear_lsb, data_swab, as, true, NULL); > } > > /* return < 0 if error, otherwise the number of bytes loaded in memory */ > @@ -448,7 +448,7 @@ int load_elf_ram(const char *filename, > void *translate_opaque, uint64_t *pentry, uint64_t *lowaddr, > uint64_t *highaddr, int big_endian, int elf_machine, > int clear_lsb, int data_swab, AddressSpace *as, > - bool load_rom) > + bool load_rom, SectionsData *sections) > { > int fd, data_order, target_data_order, must_swab, ret = ELF_LOAD_FAILED; > uint8_t e_ident[EI_NIDENT]; > @@ -488,11 +488,11 @@ int load_elf_ram(const char *filename, > if (e_ident[EI_CLASS] == ELFCLASS64) { > ret = load_elf64(filename, fd, translate_fn, translate_opaque, > must_swab, > pentry, lowaddr, highaddr, elf_machine, clear_lsb, > - data_swab, as, load_rom); > + data_swab, as, load_rom, sections); > } else { > ret = load_elf32(filename, fd, translate_fn, translate_opaque, > must_swab, > pentry, lowaddr, highaddr, elf_machine, clear_lsb, > - data_swab, as, load_rom); > + data_swab, as, load_rom, sections); > } > > fail: > diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c > index 7dacd6d827..841d05160a 100644 > --- a/hw/i386/multiboot.c > +++ b/hw/i386/multiboot.c > @@ -125,7 +125,7 @@ int load_multiboot(FWCfgState *fw_cfg, > { > int i; > bool is_multiboot = false; > -uint32_t flags = 0; > +uint32_t flags = 0, bootinfo_flags = 0; > uint32_t mh_entry_addr; > uint32_t mh_load_addr; > uint32_t mb_kernel_size; > @@ -134,6 +134,7 @@ int load_multiboot(FWCfgState *fw_cfg, > uint8_t *mb_bootinfo_data; > uint32_t cmdline_len; > struct multiboot_header *multiboot_header; > +SectionsData sections; > > /* Ok, let's see if it is a multiboot image. > The header is 12x32bit long, so the latest entry may be 8192 - 48. */ > @@ -161,37 +162,8 @@ int load_multiboot(FWCfgState *fw_cfg, > if (flags & MULTIBOOT_VIDEO_MODE) { > fprintf(stderr, "qemu: multiboot knows VBE. we don't.\n"); > } > -if (!(flags & MULTIBOOT_AOUT_KLUDGE)) { > -uint64_t elf_entry; > -uint64_t elf_low, elf_high; > -int kernel_size; > -fclose(f); > > -if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) { > -fprintf(stderr, "Cannot load x86-64 image, give a 32bit one.\n"); > -exit(1); > -} > - > -kernel_size = load_elf(kernel_filename, NULL, NULL, _entry, > - _low, _high, 0, EM_NONE, > - 0, 0); > -if (kernel_size < 0) { > -fprintf(stderr, "Error while loading elf kernel\n"); > -exit(1); > -} > -mh_load_addr = elf_low; > -mb_kernel_size = elf_high - elf_low; > -mh_entry_addr = elf_entry; > - > -mbs.mb_buf =
[Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers
Multiboot may load section headers and all sections (even those that are not part of any segment) to target memory. Tested with an ELF application that uses data from strings table section. Signed-off-by: Anatol Pomozov--- hw/core/loader.c | 8 +-- hw/i386/multiboot.c | 83 +--- hw/s390x/ipl.c | 2 +- include/hw/elf_ops.h | 107 ++- include/hw/loader.h | 11 +++- tests/multiboot/Makefile | 8 ++- tests/multiboot/generate_sections_out.py | 33 ++ tests/multiboot/modules.out | 22 +++ tests/multiboot/run_test.sh | 6 +- tests/multiboot/sections.c | 55 tests/multiboot/start.S | 2 +- 11 files changed, 276 insertions(+), 61 deletions(-) create mode 100755 tests/multiboot/generate_sections_out.py create mode 100644 tests/multiboot/sections.c diff --git a/hw/core/loader.c b/hw/core/loader.c index 4593061445..a8787f7685 100644 --- a/hw/core/loader.c +++ b/hw/core/loader.c @@ -439,7 +439,7 @@ int load_elf_as(const char *filename, { return load_elf_ram(filename, translate_fn, translate_opaque, pentry, lowaddr, highaddr, big_endian, elf_machine, -clear_lsb, data_swab, as, true); +clear_lsb, data_swab, as, true, NULL); } /* return < 0 if error, otherwise the number of bytes loaded in memory */ @@ -448,7 +448,7 @@ int load_elf_ram(const char *filename, void *translate_opaque, uint64_t *pentry, uint64_t *lowaddr, uint64_t *highaddr, int big_endian, int elf_machine, int clear_lsb, int data_swab, AddressSpace *as, - bool load_rom) + bool load_rom, SectionsData *sections) { int fd, data_order, target_data_order, must_swab, ret = ELF_LOAD_FAILED; uint8_t e_ident[EI_NIDENT]; @@ -488,11 +488,11 @@ int load_elf_ram(const char *filename, if (e_ident[EI_CLASS] == ELFCLASS64) { ret = load_elf64(filename, fd, translate_fn, translate_opaque, must_swab, pentry, lowaddr, highaddr, elf_machine, clear_lsb, - data_swab, as, load_rom); + data_swab, as, load_rom, sections); } else { ret = load_elf32(filename, fd, translate_fn, translate_opaque, must_swab, pentry, lowaddr, highaddr, elf_machine, clear_lsb, - data_swab, as, load_rom); + data_swab, as, load_rom, sections); } fail: diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c index 7dacd6d827..841d05160a 100644 --- a/hw/i386/multiboot.c +++ b/hw/i386/multiboot.c @@ -125,7 +125,7 @@ int load_multiboot(FWCfgState *fw_cfg, { int i; bool is_multiboot = false; -uint32_t flags = 0; +uint32_t flags = 0, bootinfo_flags = 0; uint32_t mh_entry_addr; uint32_t mh_load_addr; uint32_t mb_kernel_size; @@ -134,6 +134,7 @@ int load_multiboot(FWCfgState *fw_cfg, uint8_t *mb_bootinfo_data; uint32_t cmdline_len; struct multiboot_header *multiboot_header; +SectionsData sections; /* Ok, let's see if it is a multiboot image. The header is 12x32bit long, so the latest entry may be 8192 - 48. */ @@ -161,37 +162,8 @@ int load_multiboot(FWCfgState *fw_cfg, if (flags & MULTIBOOT_VIDEO_MODE) { fprintf(stderr, "qemu: multiboot knows VBE. we don't.\n"); } -if (!(flags & MULTIBOOT_AOUT_KLUDGE)) { -uint64_t elf_entry; -uint64_t elf_low, elf_high; -int kernel_size; -fclose(f); -if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) { -fprintf(stderr, "Cannot load x86-64 image, give a 32bit one.\n"); -exit(1); -} - -kernel_size = load_elf(kernel_filename, NULL, NULL, _entry, - _low, _high, 0, EM_NONE, - 0, 0); -if (kernel_size < 0) { -fprintf(stderr, "Error while loading elf kernel\n"); -exit(1); -} -mh_load_addr = elf_low; -mb_kernel_size = elf_high - elf_low; -mh_entry_addr = elf_entry; - -mbs.mb_buf = g_malloc(mb_kernel_size); -if (rom_copy(mbs.mb_buf, mh_load_addr, mb_kernel_size) != mb_kernel_size) { -fprintf(stderr, "Error while fetching elf kernel from rom\n"); -exit(1); -} - -mb_debug("qemu: loading multiboot-elf kernel (%#x bytes) with entry %#zx\n", - mb_kernel_size, (size_t)mh_entry_addr); -} else { +if (flags & MULTIBOOT_AOUT_KLUDGE) { /* Valid if mh_flags sets MULTIBOOT_AOUT_KLUDGE. */ uint32_t mh_header_addr = ldl_p(_header->header_addr);