From: devShadow <devShadow@xacks.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Debugging GRUB2 with GDB and QEMU
Date: Sat, 13 May 2006 14:45:37 -0400 [thread overview]
Message-ID: <44662951.2050600@xacks.com> (raw)
In-Reply-To: <20060512132007.GA88582@meta.morph.sk>
Hi, thanks for the help with debugging modules. I have a module that I
created and still need a little assistance in getting gdb to break in my
module's grub_cmd_*. I am able to connect to QEMU with gdb and when I
load the module, gdb loads the symbol table for my module.
But, when I set a breakpoint at the address of the first operation in my
module, gdb doesn't break when I execute the command in GRUB. If it has
something to do with the aliases you mention at the bottom of your
message, could you elaborate a little more or direct me in the right
direction?
Thanks
David Johnson
Lubomir Kundrak wrote:
> I wrote some GDB macros that might be helpful for people
> that want to debug GRUB 2 modules with QEMU. [1]
>
> [1] http://NetBSD.sk/~lkundrak/misc/grub2-gdb/
>
> The file genmk.rb.diff is a patch to makefile-generator
> script, that makes the build system leave output files with
> debugging information. Of course, one has have ruby interpreter
> to regenerate the makefiles and compile GRUB with -g
> afterwards.
>
> Second file is .gdbinit, the GDB initialization file. It is
> commented, so there is no need to describe it here. It basically
> passes the information extracted from list headed by grub_dl_head to
> the perl script, gmodule.pl, and loads its output. It also
> sets a breakpoint whose command list contains macro for loading
> proper symbol file each time a module is loaded. (I know the work
> could be done without the help of a Perl script, but it would
> be far more complicated, I guess)
>
> Another note worth mentioning is that you'll probably want
> to add aliases for some functions, so that all gdb facilities
> will work correctly. You will at least want to define the symbol
> 'main' for backtraces to stop at the right place. Some facilities
> also want the function 'malloc' to be defined. So, you'll
> probably have to add something like
>
> .globl main
> main = codestart
>
> to assembly language sources or
>
> malloc() __attribute__ ((alias("grub_malloc")));
>
> to C files.
>
> I hope this will be useful to at least some of you. Best regards!
> Lubo.
>
next prev parent reply other threads:[~2006-05-13 18:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-12 13:20 Debugging GRUB2 with GDB and QEMU Lubomir Kundrak
2006-05-13 4:38 ` Yoshinori K. Okuji
2006-05-18 12:27 ` Lubomir Kundrak
2006-05-18 13:35 ` Hollis Blanchard
2006-05-19 10:16 ` Lubomir Kundrak
2006-05-19 11:25 ` Yoshinori K. Okuji
2006-05-13 5:28 ` RE : " Eric Salomé
2006-05-13 18:45 ` devShadow [this message]
2006-05-14 14:01 ` Lubomir Kundrak
2006-05-17 21:15 ` David Johnson
2006-05-13 22:16 ` RE : " Eric Salomé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44662951.2050600@xacks.com \
--to=devshadow@xacks.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.