grub-devel
[Top][All Lists]
Advanced

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

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


From: Peter Jones
Subject: Re: [PATCH v2 2/2] Make a "gdb" dprintf that tells us load addresses
Date: Wed, 1 Dec 2021 11:08:39 -0500
User-agent: NeoMutt/20180716

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.

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

-- 
        Peter




reply via email to

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