grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] Make a "gdb" dprintf that tells us load addresses.


From: Michael Schierl
Subject: Re: [PATCH 2/2] Make a "gdb" dprintf that tells us load addresses.
Date: Mon, 18 Oct 2021 23:04:59 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0


Hello,


Am 18.10.2021 um 22:29 schrieb Glenn Washburn:

I can't say I'm a fan of another special variable, but I'd also be fine
with that route. Another route might be a (proc) file, eg. "/gsyms",
which outputs add-symbol-file lines for all loaded modules. This could
be put in its own module, eg. gdb-syms, which would address the
increasing the core image size concern below.

To be honest I was not even aware that (proc) was a thing in Grub. In
fact, procfs is not loaded in any grub I have here, and loading it does
not make any files appear in it either (if I can trust the ls command).

If I understand this correctly, you're thinking I'm talking about
*appending* a new line to the debug message. I'm talking about
*prepending*. So we're on the same page, the entire message is
formatted currently as "file:line:<debug message>".

I'm not sure I understand the last sentence, the debug message as
proposed in the patch is already a multi-line message.

Ok, then rather "every fourth line" instead of "every second line"?

I have to admit I did not actually apply and test the patch. From the
patch content, when not using qdprintf, it looked to me that the output
would be similar to

kern/efi/init.c:2222 add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/kernel.exec \\
 40005678 -s .data 40009876
kern/dl.c:1111 add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/efidisk.debug \\
 10005678 -s .data 10009876
kern/dl.c:1111 add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/ext2.debug \\
 20005678 -s .data 20009876
kern/dl.c:1111 add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/gfxterm.debug \\
 30005678 -s .data 30009876
kern/dl.c:1111 add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/normal.debug \\
 30005678 -s .data 30009876


And with prepending a newline, it would look like this:

kern/efi/init.c.c:2222
add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/kernel.exec \\
 40005678 -s .data 40009876
kern/dl.c:1111
add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/efidisk.debug \\
 10005678 -s .data 10009876
kern/dl.c:1111
add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/ext2.debug \\
 20005678 -s .data 20009876
kern/dl.c:1111
add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/gfxterm.debug \\
 30005678 -s .data 30009876
kern/dl.c:1111
add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/normal.debug \\
 30005678 -s .data 30009876


And what you need to copy into gdb would be

add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/kernel.exec \\
 40005678 -s .data 40009876
add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/efidisk.debug \\
 10005678 -s .data 10009876
add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/ext2.debug \\
 20005678 -s .data 20009876
add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/gfxterm.debug \\
 30005678 -s .data 30009876
add-symbol-file \\
/usr/lib/debug/usr/lib/grub/x86_64-efi/normal.debug \\
 30005678 -s .data 30009876

If that assumption is wrong, I am sorry for misinterpreting the patch
and stealing your time.

Interesting idea. Also, I had thought of having an in memory ring-buffer
for playing back debug log on a live grub.

The interesting question is how to play it back as in my experience,
GRUB usually locks up when I need this. So there is no real way to
return to the shell so you could play it back again. (On the other hand,
this would require to synchronously write the logs to disk and not
buffer them, or you would miss the last few). But probably there are
other cases where you actually could return to the prompt.


Regards,


Michael



reply via email to

[Prev in Thread] Current Thread [Next in Thread]