grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Make gdb debugging a bit less painful


From: Robert Millan
Subject: Re: [PATCH] Make gdb debugging a bit less painful
Date: Thu, 17 Apr 2008 22:11:07 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

On Thu, Apr 17, 2008 at 01:53:21PM +0200, Lubomir Kundrak wrote:
> 
> On Tue, 2008-04-15 at 15:38 +0200, Robert Millan wrote:
> > On Tue, Apr 15, 2008 at 12:30:40AM +0200, Lubomir Kundrak wrote:
> > > diff -rup grub-1.95.orig/kern/main.c grub-1.95/kern/main.c
> > > --- grub-1.95.orig/kern/main.c    2007-01-29 15:31:36.000000000 +0100
> > > +++ grub-1.95/kern/main.c 2007-01-30 18:29:55.000000000 +0100
> > > @@ -106,6 +106,14 @@ grub_load_normal_mode (void)
> > >    grub_errno = GRUB_ERR_NONE;
> > >  }
> > >  
> > > +#ifndef GRUB_UTIL
> > > +/*
> > > + * Let GDB find the stack top
> > > + */
> > > +void
> > > +main (void) __attribute__ ((alias("grub_main")));
> > > +#endif
> > 
> > grub_main() isn't always the function we want for top of the stack.  For
> > example cmain() in kern/ieee1275/cmain.c does quite a bit of things already.
> > 
> > I'm not sure what would be an ellegant way to solve this... :-/
> 
> Well, then more preprocessor conditionals come into play. Wold there be
> any problems with that?

Now that I think of it, is there any reason for doing all the cmain()
cruft before grub_main() ?  Getting to grub_main() only requires a working
stack, which we have, and grub_main() inmediately returns control back to
architecture-specific code in grub_machine_init().

So why not move from:

  _start -> cmain -> grub_main

to:

  _start -> grub_main -> grub_machine_init -> cmain

?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)




reply via email to

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