On 2012-03-17 05:08, Scott Moser wrote: > The previous code did not treat the case where load_end_addr was 0 > specially. The multiboot specification says the following: > * load_end_addr > Contains the physical address of the end of the data segment. > (load_end_addr - load_addr) specifies how much data to load. This > implies that the text and data segments must be consecutive in the > OS image; this is true for existing a.out executable formats. If > this field is zero, the boot loader assumes that the text and data > segments occupy the whole OS image file. > > This was raised initially as launchpad bug > https://bugs.launchpad.net/qemu/+bug/957622 > > diff --git a/hw/multiboot.c b/hw/multiboot.c > index b4484a3..b1e04c5 100644 > --- a/hw/multiboot.c > +++ b/hw/multiboot.c > @@ -202,10 +202,16 @@ int load_multiboot(void *fw_cfg, > uint32_t mh_bss_end_addr = ldl_p(header+i+24); > mh_load_addr = ldl_p(header+i+16); > uint32_t mb_kernel_text_offset = i - (mh_header_addr - mh_load_addr); > - uint32_t mb_load_size = mh_load_end_addr - mh_load_addr; > - > + uint32_t mb_load_size = 0; > mh_entry_addr = ldl_p(header+i+28); > - mb_kernel_size = mh_bss_end_addr - mh_load_addr; > + > + if (mh_load_end_addr) { > + mb_kernel_size = mh_bss_end_addr - mh_load_addr; > + mb_load_size = mh_load_end_addr - mh_load_addr; > + } else { > + mb_kernel_size = kernel_file_size - mb_kernel_text_offset; > + mb_load_size = mb_kernel_size; > + } > > /* Valid if mh_flags sets MULTIBOOT_HEADER_HAS_VBE. > uint32_t mh_mode_type = ldl_p(header+i+32); Almost everything should go to upstream directly these days, including this fix. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
