All of lore.kernel.org
 help / color / mirror / Atom feed
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.
> 



  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.