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

[Glenn Washburn]

On Sat, 16 Oct 2021 19:48:45 +0200
Michael Schierl <schierlm@gmx.de> wrote:

> Glenn Washburn <development@efficientek.com> writes:
> > Robbie Harwood <rharwood@redhat.com> wrote:
> >
> > They turn on debug=all because they don't know in what conditional(s)
> > would give them useful debug information. This will spew a lot of debug
> > messages to the screen, including the messages output by this patch.
> 
> BTDT.
> 
> > message by conditional, allows the user to iteratively pare down debug
> > log messages so that the ones of value have a greater likelihood of
> > being on the limited screen realestate. This would look like, for
> > example:
> >
> >   set debug=all,-gdb,-disk,-lexer,-alloc
> 
> I would second that.

Great, I'm not the only one. I'll see about submitting that patch
sooner than later then.

> > Now the patch as is does not show the file:line prefix, and wouldn't
> > show the conditional after my patch. So the user has no way of knowing
> > what conditional should be used to disable the gdb output.
> 
> In fact, is there even a sensible scenario where having these messages
> included when debug=all is set? I generally use debug=all to get some
> first idea about which driver/device may be causing the boot failure,
> and module load addresses will never help with that.
> 
> Maybe do not trigger this message on debug=all, or use a completely
> different environment variable?

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.

> 
> I am also unaware how exactly to debug grub in gdb on various platforms,
> do you need special build flags for it? If yes, this functionality could
> be limited to that build flags. Especially since if I did not miss
> anything, this patch only provides value for efi platform (in an obscure
> edge case, from my point of view), yet increases core image size for all
> platforms.
> 
> > On the otherhand, since you're able to copy paste, I'm guessing you're
> > on a serial line or VM and not on in the situation I'm describing. In
> > which case, without the proposed "\n" modification, having the file:line
> > prefix is an extremely minor inconvenience (you'll have to find the
> > start of the add-symbol-file, which won't be at the beginning of the
> > line). And you can copy-paste, you likely can search that output
> > anyway.
> 
> I presume that typical GRUB loads will load dozens of modules, resulting
> in dozens of debug outputs, which may often end up on adjacent lines. In
> case of a line prefix, you would need to use sed (or some block editor
> features) to get rid of the prefixes. In case of a newline after the
> debug message, one would need to use grep (or remove every second line
> from the output).

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.

> > Why do I care? I've been that guy trying to figure out a boot issue
> > with too much noise in the debug log messages pushing the messages I
> > needed to see off the screen (and the source wasn't readily available).
> > And no pager is not always an option if you have hundreds of pages of
> > log messages to scroll through, it takes forever.
> 
> As I have been in the same situation before, too, I second that. I would
> also like a feature so that debug messages (or all output) get spewn
> into a file (overwriting existing bytes similar to how grub_env works,
> acting like a ring buffer on the file). So you could boot some recovery
> envionment to create a sufficiently large file, set debug=all, let debug
> logs write into that file, and then analyze them after another reboot
> into said environment. Or when GRUB is booted from a USB key, the file
> can be created/analyzed on another machine.

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

> 
> This may not help if nothing boots on that machine, but in my experience
> there is either some non-Linux operating system already installed on
> that machine that fails to boot Linux from GRUB, or at least a recovery
> environment from another OS can be booted.
> 
> > I don't think we need to agree (that is for you to agree that the issue
> > I'm describing is something to be concerned about). However, like I
> > said, I think we can both be satisfied by not leaving out the file:line
> > and to prepend "\n" to "add-symbol-file" so that it will start on a new
> > line. So I'll ask again. Is my proposal an acceptable modification for
> > the need that you have?
> 
> Another way (if possible, I don't know GRUB internals enough) would be
> to provide a module similar to lsmod that shows this output for all
> loaded modules. Users could load it if they want to use gdb and invoke
> it during their debug session. Then copy&paste the output in one single
> block.

That's another idea, a "get-gdb-symbol-file" command.

Glenn