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

[Daniel Kiper]

On Wed, Dec 01, 2021 at 11:08:39AM -0500, Peter Jones wrote:
> On Tue, Nov 30, 2021 at 05:08:20PM +0100, Daniel Kiper wrote:
> > On Mon, Nov 29, 2021 at 06:11:36PM -0500, Robbie Harwood wrote:
> > > Daniel Kiper <dkiper@net-space.pl> writes:
> > >
> > > > On Wed, Nov 03, 2021 at 02:22:07PM -0400, Robbie Harwood wrote:
> > > >> From: Peter Jones <pjones@redhat.com>
> > > >>
> > > >> Add a grub_dprintf() call during platform init and during module 
> > > >> loading
> > > >> that tells us the virtual addresses of the .text and .data sections of
> > > >> grub-core/kernel.exec and any modules it loads.
> > > >>
> > > >> Specifically, it displays them in the gdb "add-symbol-file" syntax, 
> > > >> with
> > > >> the presumption that there's a variable $grubdir that reflects the path
> > > >> to any such binaries.
> > > >
> > > > Could you tell us why this thing has to be displayed as a part of debug
> > > > messages? Could you create a separate command which would do the same?
> > >
> > > I don't follow what you're suggesting.  It's debug output and gdb is a
> > > debugger.  What would you have it do instead?
> >
> > I cannot see any reason of displaying this kind of stuff as a part of
> > debug messages. I think we should have a separate command, e.g.
> > give_me_these_load_addresses ;-), in the GRUB which will produce list
> > of commands needed to be executed in the gdb.
>
> I'm not seeing how that will fulfill the goals.  Typically when I need
> gdb in grub, it's well before /commands/ actually work at all.

OK, makes sense for me. However, how do you enable debugging then? Do you
use an early GRUB cfg? If yes why could not we use command instead of
setting the variable there? Hmmm... I can only see one advantage of your
solution over mine. A gdb command is printed and available immediately
after loading a module into the memory. Disadvantage, small one?, is
that it is mixed with the other debug messages.

> I definitely *do* see your point about silencing this when SB is
> enabled; that's useful feedback.

Great! Thanks!

Daniel