From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1QDEjQ-00064P-TV for mharc-grub-devel@gnu.org; Fri, 22 Apr 2011 07:41:04 -0400 Received: from eggs.gnu.org ([140.186.70.92]:50275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDEjO-00063Z-6B for grub-devel@gnu.org; Fri, 22 Apr 2011 07:41:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QDEjM-0002wz-HI for grub-devel@gnu.org; Fri, 22 Apr 2011 07:41:02 -0400 Received: from smarthost02.mail.zen.net.uk ([212.23.3.141]:49310) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDEjM-0002wf-5S for grub-devel@gnu.org; Fri, 22 Apr 2011 07:41:00 -0400 Received: from [82.69.40.219] (helo=riva.pelham.vpn.ucam.org) by smarthost02.mail.zen.net.uk with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1QDEjK-0007Rz-HN for grub-devel@gnu.org; Fri, 22 Apr 2011 11:40:58 +0000 Received: from cjwatson by riva.pelham.vpn.ucam.org with local (Exim 4.72) (envelope-from ) id 1QDEjI-0002vD-PX for grub-devel@gnu.org; Fri, 22 Apr 2011 12:40:56 +0100 Date: Fri, 22 Apr 2011 12:40:56 +0100 From: Colin Watson To: grub-devel@gnu.org Subject: Re: Question: how to add new menu functionality Message-ID: <20110422114056.GD9163@riva.ucam.org> References: <1303466621.24395.8.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1303466621.24395.8.camel@localhost.localdomain> User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-Smarthost02-IP: [82.69.40.219] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 212.23.3.141 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 11:41:03 -0000 On Fri, Apr 22, 2011 at 06:03:41AM -0400, Stephen Torri wrote: > I am using the released grub-1.98 code for my development. I recommend using 1.99~rc2 or a current bzr checkout, if you can. Not just on general principles, but because its rewritten build system is really a great deal easier to modify in the kinds of ways you need. 1.98's was generally a pain. > The problem I am having is how to add new functionality to the > 'normal' module. I would like to add a new feature to the code using > some functions that don't presently exist in the code. When I coded > the functions I had to manually edit def-normal.lst to get the > compiler to be happy and successfully complete the build. That's a sign that you've missed something; you should never have to edit that file. > This was not enough because when used the new grub2 loader on a drive > I got an error saying "error: the symbol 'work' not found" is > displayed. This error code is reported because the symbol cannot be > found in a symbol table. So to summarize what I am asking: > > 1. How do you configure the build system to compile with new files (e.g. > new command for command line)? In 1.98, you need to find the appropriate targets in conf/*.rmk (they'll either be in common.rmk or a platform-specific file - you may need to edit both), and add the new files there. In 1.99, you need to edit grub-core/Makefile.core.def and add lines for the files you're adding to the appropriate target block, either with 'common =' if they're platform-independent, or with a platform-specific prefix. Follow the patterns of the surrounding lines. In either case, you need to run ./autogen.sh and (re-)run ./configure before building. This may require additional build system dependencies beyond those required to build GRUB itself; see the INSTALL file. It helps to work in a bzr checkout, so that you can use the usual version control commands to keep track of what you've changed (even if you never commit anything). > 2. How do you configure the build system to compile with new functions > contained in existing files? Using new functions entirely within a single file requires no special actions, in either 1.98 or 1.99. If you're using functions in file A that are defined in file B, you'll need to make sure that file A includes any necessary headers (conventionally in include/grub/, using '#include '), and that any targets that involve file A also involve file B, much as you would for any normal C project. See my answer to your previous question for the exact build system mechanics. > 3. Is there a tutorial on how to develop for Grub2? If I missed that in > my search I am sorry for not reading that first. I've seen the odd one floating around, but they've generally had substantial flaws (even one of the best I saw involved editing generated build system files rather than the source files, which is unwise) and/or not been up to date. We recently started writing a developer manual, which is in docs/grub-dev.texi in 1.99~rc2 (or a current bzr checkout) although not yet on the web. It may well not yet be what you need, but it should be a useful start and we'd appreciate feedback from people trying to use it. > 4. How do you debug your Grub2 builds? The web had references to a patch > to add in GDB functionality. That patch is pretty old and won't apply to current builds. I recently started attempting to bring it up to date, although I've been very busy and so don't have anything to show yet. I have a few train journeys and hotel stays in my near future, and may well hack on it then. For most purposes, using grub_dprintf and 'set debug=all' (or a more limited set of debug options) is good enough: add debugging output until it shows what you need. It helps enormously if your code can be run in a rescue image that you can run in a virtual machine. In a built 1.98 tree, where the 'rescue-disk' directory is one you've created with any other files you need in the rescue image: ./grub-mkrescue --override-directory=. --output=grub.iso rescue-disk In 1.99: ./grub-mkrescue --grub-mkimage=./grub-mkimage --override-directory=grub-core --output=grub.iso rescue-disk You can then boot this in 'kvm -cdrom grub.iso' or similar. This greatly speeds up the debugging cycle, versus having to boot it on real hardware. In some cases, particularly if you're working on a failure very early on, you need to resort to stronger techniques. For instance, a serial console means that you can see more debugging output, and can help if the debugging output you need is from the video subsystem (since of course changing video modes loses screen contents). GDB-over-serial will no doubt be great when we get that far. It's also possible to use GDB in conjunction with QEMU to debug some parts of GRUB even without special support in GRUB, if you're sufficiently determined and can cope with the lack of symbols. I wrote about this on my blog recently: http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2011-03-14-wubi-bug-693671.html Depending on what you're doing, you can often debug large parts of GRUB in userspace, which makes hacking on GRUB a lot more fun. For instance, you can use grub-probe or grub-fstest to debug filesystem drivers, and you can use grub-emu to debug some other things if you can live with its eccentricities. As general advice, it's worth spending a little time up-front to attempt to move your problem into the most congenial debugging environment available; GRUB offers developers several ways to do that, and so it is rarely necessary to resort to heroic techniques unless you are working on the lowest levels of machine-dependent code. Cheers, -- Colin Watson [cjwatson@ubuntu.com]