From: "Eric Salomé" <esalome@ctx.net>
To: "'The development of GRUB 2'" <grub-devel@gnu.org>
Subject: RE : Debugging GRUB2 with GDB and QEMU
Date: Sat, 13 May 2006 07:28:13 +0200 [thread overview]
Message-ID: <000f01c6764e$090c1030$0b00a8c0@yoda> (raw)
In-Reply-To: <20060512132007.GA88582@meta.morph.sk>
Hi Lubomir,
Thanks for the scripts. It is just what I was looking for.
Meanwhile, since my last email, I have done something foolish.
I've coded in grub's sources just the same algorithm you provide but
I've clumbered the sources with new functions those purpose is only for
debugging while you are doing all the job outside of the sources, and
one might think it's better the way you do.
1) Got Ruby and change the makefiles just the way you do to get .elf
files with debugging info. (I've setup for a different extension but
I'll change for .elf)
2) Added a very few lines to grub_load_segments() to get the name of the
section along with its load address in mod->segment.
(You might want that to get ride of the readelf and perl script)
3) Build in a buffer, during build_load_core() and grub_load_segments()
processing, the string
"filename.elf load_addr -s .text 0x23888 ... "
print it on the screen with grub_dprintf.
4) Call a function with that string argument to be caught by a .gdbinit
script to launch the add-symbol-file command before the call to
(mod->init(mod)).
I first thought I could just get along with add-symbol-file command to
gdb, but I was frustrated I could not set breakpoint ahead of time and
then have it resolved when the module is loaded .... I was in the mood
of doing C development so I've been overkilling again :
Before I even finished the .gdbinit script, I've changed my mind and
done "one" step further :
5) Added the "filename.elf -s .text 0x23234 ... " to the list of
link_maps maintained by ld.so (actually ld.so complains a little but
I'll fix that later) and do the call to _ld_debug_state() to generate a
shlib event in gdb.
6) Changed the solib-svr4.c in gdb 6.1 so that it can handle loading ELF
file with instructions to load each segment separately at the right
place.
So I am running with a modified gdb that understand grub's way of
loading modules on the fly.
If you think it can be of general interest, we can start from here to
define a GDB interface to Grub 2. Otherwise, I'll use Ludomir external
scripts since I don't want to maintain separate source files from the
official delivery.
Note that if we change somewhat the way grub load modules and allocate
first the memory to contain all the segments, lying right one after
another in memory, we won't have to change gdb anymore (step 6).
Best regards,
_________________________________________
Eric Salomé - Paris, France
next prev parent reply other threads:[~2006-05-13 5:28 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 ` Eric Salomé [this message]
2006-05-13 18:45 ` devShadow
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='000f01c6764e$090c1030$0b00a8c0@yoda' \
--to=esalome@ctx.net \
--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.