From 5e578a942d5bdb9b0e4e09a8a7ed5c47a1487bf2 Mon Sep 17 00:00:00 2001 From: Maria Pana Date: Thu, 1 Aug 2024 19:30:28 +0300 Subject: [PATCH] Fix linter error --- content/blog/2024-08-01-gsoc-multiboot2.mdx | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/blog/2024-08-01-gsoc-multiboot2.mdx b/content/blog/2024-08-01-gsoc-multiboot2.mdx index c567c8a7..d4305762 100644 --- a/content/blog/2024-08-01-gsoc-multiboot2.mdx +++ b/content/blog/2024-08-01-gsoc-multiboot2.mdx @@ -54,13 +54,14 @@ For the purpose of debugging, I needed the `.module` files. Obviously, the first module I looked into was `relocator.module`. I then needed to determine the base address where I had added my breakpoint. The plan was to: + - print the address of the function using `__builtin_return_address(0)` - object dump the module to find the offset of the function - get the base address by substracting the offset from the address Pretty straightforward, right? Normally, yes. -But here... +But here? Well, not quite. After performing this process with the printed address, `gdb` was showing code from `malloc_in_range` instead of `grub_relocator_alloc_chunk_align`. Additionally, it did not match the assembly (which was an infinite loop with a dummy value). @@ -77,7 +78,7 @@ But after the preprocessor replaced the call with the definition including `grub The backtrace also revealed the culprit for the "out of memory" error: the `grub_relocator32_boot` function had been called earlier with a null relocator. To see when the relocator changed to null, I set a watchpoint, which quickly indicated the obstacle and allowed for an easy fix. -Drumroll, please... +Drumrolls, please! Ladies and gentlemen, we successfully booted into Unikraft! 🎉 ## Monkey see, Monkey do