From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1nJSHF-0007JB-N1 for mharc-grub-devel@gnu.org; Sun, 13 Feb 2022 22:43:49 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJSHD-0007J0-Lp for grub-devel@gnu.org; Sun, 13 Feb 2022 22:43:47 -0500 Received: from [2607:f8b0:4864:20::82c] (port=42872 helo=mail-qt1-x82c.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nJSHA-0005YV-TA for grub-devel@gnu.org; Sun, 13 Feb 2022 22:43:47 -0500 Received: by mail-qt1-x82c.google.com with SMTP id s1so14408138qtw.9 for ; Sun, 13 Feb 2022 19:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficientek-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=OqWgH4If5YxNVIS7BKxjHIuXiDiWXlXw0ToJca8XCio=; b=a/gqr8vjzj5MGyheQNP+x63/NbFOBnPaZyHMHK5FatChYzJOF8gJarSxrdAJ/l2eFq yvPGdmWtEBOcBIMTV1yJphhxUG1paaXiRNQXnjmfapqaIs2HkDtLkRqOhnBSsnKOn+/g Nqe2LCbYaPdPnif1kAyaLmV35UQS2ydRfYG9KcbVjTszGy2jHtQE3jSWqKHawPI//nNr +y9XrYv1z1xK2ew+APFrdMKKC5zXEeo9vGFBc9JeA4jxabLKTMrZeONXtrRso5cVHc6Q Xbaup0EpsZg1aMyCvPipOjfG5+CDe0k+Sq7/qiTk2Y9Uaq4OyRge/PNZJ8wg0cxJHRCj Yv9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=OqWgH4If5YxNVIS7BKxjHIuXiDiWXlXw0ToJca8XCio=; b=dH4tMbSpAUe2qrIoRAZBDU4qHi95kQEXVlPz79UQ3X81pwMcEdtMdw/OGZkWQttuO3 M4ORgLlNlBpBAS51SnAU/ngnDKUSQnw6PG9wU1NizAxHLlQmGHLahQ8zqoV06F3LsowP WTEJ/e32bBaRFFOSEj4QkLMUJdgFiSydQKTpInB4vpCf92qBRnXbw8zxIpoLiVecPsQB skFV1yC77On7aZagqzxCpdF+Ro1jlkrXYL8375DNJf9eyd5T3j5vOcpi+CAhkGjfTBrJ AJINyzydhfBlkzrOSFOTvTvavQSM1eLcyY726qMtlLJQbXLAreduXTpso6782dt//kf2 E9hA== X-Gm-Message-State: AOAM532FQWuIRlNJNa7hCYRAAfHIjIrpWRDMIN8jfVPKIhNXNRe/w2a8 Un7VJcF98r7V+DPxk01M+HavCg== X-Google-Smtp-Source: ABdhPJzhgalyM9DHgnNQZuGYdy5LmaOh+CB6HxP/gfcNSCad30aQdrGfurb0oA6zX0hopCW9oHqkLQ== X-Received: by 2002:ac8:5741:: with SMTP id 1mr8147881qtx.644.1644810223457; Sun, 13 Feb 2022 19:43:43 -0800 (PST) Received: from localhost.localdomain (garza.riseup.net. [198.252.153.109]) by smtp.gmail.com with ESMTPSA id z19sm17755800qtj.77.2022.02.13.19.43.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Feb 2022 19:43:42 -0800 (PST) From: Glenn Washburn To: Daniel Kiper , grub-devel@gnu.org Cc: Peter Jones , Robbie Harwood , Glenn Washburn Subject: [PATCH 0/8] GDB script fixes and improvements Date: Sun, 13 Feb 2022 21:42:37 -0600 Message-Id: X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::82c (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::82c; envelope-from=development@efficientek.com; helo=mail-qt1-x82c.google.com X-Spam_score_int: -2 X-Spam_score: -0.3 X-Spam_bar: / X-Spam_report: (-0.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_HP_HELO_NORDNS=0.785, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 03:43:47 -0000 This is a collection of fixes and improvements mostly to the GDB script, gdb_grub. I don't think the first 4 need commnt. A major benefit added in patch #5 is the ability to properly load symbols on EFI targets given the load address for the text and data segments. This is written as a shell script in the GDB script primarily because I'm not familiar with the Python API. I think it would probably be better written in Python, though. Daniel what do you think about using Python in the GDB script? First of all, I get the impression that this script isn't used much (but I'd like to know if I'm wrong about that), so I suspect changes won't affect many people one way or the other. And second, I think its reasonable to assume these days that people's GDB is compiled with Python support. Patch #6 has code stolen from the patch by Peter Jones[1]. I've added a Co-developed-by tag. Let me know if there's something different I should do. I've removed the printing of lines for each module as this is unnecessary if the kernel.exec symbols have been loaded correctly (see load_all_modules in gdb_grub). Also, I've made the printed message for loading kernel.exec symbols only happen if enabled by setting PRINT_GDB_SYM_LOAD_CMD to a non- zero value in config.h.in. Ultimately, I think a better solution is to check the EFI variables for a certain value and enable the print using that. This way support would always be compiled in and can still be enabled very early in the GRUB boot process. However, I'm not sure what that variable should be, or if we should just create our own variable. Someone more experienced in EFI than I could help with that or say that using an EFI var would be unadvisable. Testing on QEMU with OVMF firmware, shows that GRUB will be loaded to the same address consistently so long as the binary hasn't changed. This is nice because by the time you get the message with the right parameters needed to load the symbols you may have already passed by code you wanted to break on. So you can use the same parameters to load the symbols before GRUB executes and set break points as early as you want in GRUB code. I'm not sure if this is true of real hardware, but I suspect it is. If this is so, then Daniel's idea of making this a command may make sense as well, so that GRUB doesn't need to be recompiled in "debug mode" to get this address. Of course, if GRUB is failing before module initialization, the module won't work. Patch #7 adds a check if the build was for an EFI platform and runs the dynamic code at startup if so. As noted in the commit message, without this the user must remember to first remove the symbols loaded at the statically positioned offset. Otherwise, symbols will be multiply defined and GDB uses the first ones defined by default. It was suggested by Vladimir that targets with platform as EFI were all the dynamic ones[2], but 10+ years later this may have changed. Other target tests can be added as needed for ones that are dynamic but are not EFI. Patch #8 This is a work around for a strange issue where GDB is stopping before the stack frame has been setup when breaking on grub_dl_add(). But GDB thinks that the stack frame has been setup. I'm not sure what is causing this (not using -fomit-frame-pointer and don't see any obvious culprits in other GCC compile options). I also don't particularly like this solution, but its the best one I've found. I originally was going up a frame in grub_dl_add() and getting the mod variable there, but that assumes knowledge of the caller. I'd like to set a break point on the instruction that I'd get to by issuing a "step" in GDB after the break on grub_dl_add, but I don't see a way to do that. Another option is to set an unused label in grub_dl_add() and do a tbreak on the label, but I was wanting to avoid code changes. Maybe this is acceptable though. Glenn [1] https://lists.gnu.org/archive/html/grub-devel/2021-11/msg00008.html [2] https://lists.gnu.org/archive/html/grub-devel/2011-11/msg00069.html Glenn Washburn (8): gdb: Move runtime module loading into runtime_load_module gdb: If no modules have been loaded, do not try to load module symbols gdb: Do not lazy load module symbols gdb: Prevent wrapping when writing to .segments.tmp gdb: Add functions to make loading from dynamically positioned targets easier gdb: If enabled, print line used to load EFI kernel symbols when using gdb_grub script gdb: Conditionally run GDB script logic for dynamically or statically positioned GRUB gdb: Get correct mod variable value config.h.in | 3 ++ grub-core/gdb_grub.in | 109 ++++++++++++++++++++++++++++++++++---- grub-core/gmodule.pl.in | 2 +- grub-core/kern/efi/efi.c | 4 +- grub-core/kern/efi/init.c | 25 ++++++++- include/grub/efi/efi.h | 2 +- 6 files changed, 131 insertions(+), 14 deletions(-) -- 2.27.0