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

[Glenn Washburn]

On Mon, 18 Oct 2021 23:04:59 +0200
Michael Schierl <schierlm@gmx.de> wrote:

> 
> 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).

Its not much of a thing, though I have patches to make it more of a
thing. Afaik, the only thing that currently uses (proc) is cryptodisk
with luks.

> 
> > 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.

I think we're on the same page now. I haven't tested the patch either,
but the above is my understanding as well (except that just one '\' is
output and the numbers are in '0x' prefixed hexidecimal). And I think I
understand now that you were giving helpful advice on the differences
in to extract the desired output of what I was proposing versus the
patch as is.

> > 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.

Yes, I've had issues where the issue was due to required modules not
being loaded due to misconfiguration, but it wasn't obvious because the
debug output would flash by and then go back to the menu. So still had
a working grub. But, yes, I think your proposal satisfies more cases
and harder to debug ones, but both have their place (some setups don't
have writable disks at boot).

Glenn