1 files changed, 72 insertions, 0 deletions
diff --git a/results/classifier/118/none/1512134 b/results/classifier/118/none/1512134
new file mode 100644
index 000000000..1c8076eec
--- /dev/null
+++ b/results/classifier/118/none/1512134
@@ -0,0 +1,72 @@
+kernel: 0.647
+mistranslation: 0.630
+device: 0.589
+graphic: 0.586
+semantic: 0.492
+boot: 0.432
+architecture: 0.418
+socket: 0.385
+performance: 0.377
+peripherals: 0.328
+network: 0.300
+debug: 0.280
+risc-v: 0.268
+vnc: 0.254
+VMM: 0.232
+user-level: 0.228
+register: 0.220
+ppc: 0.202
+files: 0.196
+assembly: 0.183
+virtual: 0.178
+x86: 0.175
+TCG: 0.144
+PID: 0.143
+arm: 0.136
+hypervisor: 0.124
+i386: 0.104
+permissions: 0.101
+KVM: 0.074
+
+Multiboot v1 memory map offset wrong
+
+I'm developping a multiboot kernel for multiboot v1
+My multiboot header contains the V1 magic (0x1BADB002) and the flags 0x00010243  (with enabled memory detection, and boot loader name)
+
+
+When booted in multiboot,
+Qemu gives me two pointers:
+unsigned long mmap_length;
+unsigned long mmap_addr;
+
+mmap_addr shall points to this structure:
+struct multiboot_mmap_entry
+{
+multiboot_uint32_t size;
+multiboot_uint64_t addr;
+multiboot_uint64_t len;
+multiboot_uint32_t type;
+} 
+
+
+According to the multiboot v1 specification, mmap_addr should not point  to the start of this structure, but instead, should point to the "addr "field.
+
+Work-arround:
+Detect if qemu is used using bootloader_name field.
+If it is, do NOT apply a -4 offset to mmap_addr
+
+http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multiboot
+
+I forgot to tell how i detected the issue:
+I print all the fields, and in "type", i had the size of  the next entry (and in size, i have always zero, which corresponds to the high part of addr)
+
+Hi,
+
+Have you tested your code with GRUB (Legacy) itself? Looking at code from one of my own hobby kernels, and from a hobby kernel that has largely not been written by me, both are interpreting the fields as qemu is (i.e. mmap_addr points to a multiboot_mmap_entry, and not to multiboot_mmap_entry + 4), and I know both to work just fine with GRUB.
+
+I considered the -4 offset to signify that the size field simply does not count itself, i.e. the size of one multiboot_mmap_entry is $size + 4.
+
+Max
+
+Tested today with GRUB 2.0. Indeed, mmap_entry points to the start of the structure, without a fancy offset. I guess we can close this ticket
+