Re: Kernel Tracking Question.. regarding kernel and boot files

From: Mohammed Farrag <mfarrag_at_freebsd.org>
Date: Mon, 11 Apr 2011 20:08:20 +0200
Hey All,

        Please check this. Check this to use Eclipse/Qemu for Kernel
Debugging.
http://issaris.blogspot.com/2007/12/download-linux-kernel-sourcecode-from.html
It was designed to debug linux kernel.

Regards,

Mohammed


On Sun, Apr 10, 2011 at 9:28 AM, Devin Teske <dteske_at_vicor.com> wrote:

> On Apr 9, 2011, at 9:46 PM, Julian Elischer <julian_at_freebsd.org> wrote:
>
> > On 4/9/11 2:51 PM, Chris Richardson wrote:
> >> On Sat, Apr 9, 2011 at 10:34 PM, Chuck Swiger<cswiger_at_mac.com>  wrote:
> >>
> >>> Hi, Chris--
> >>>
> >>> [ ...Reply-to: set to direct towards the most appropriate list... ]
> >>>
> >>> On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote:
> >>>>   I am totally new to FreeBSD. I was involved within project which
> will
> >>>> trace the kernel. I used ktrace but I could not get appropriate
> results
> >>>> about the files being opened. I don't see any of the boot files
> boot0-1
> >>> or 2
> >>>> in the ktrace.out file. Where did they go?
> >>> The bootstrap loader stages are what loads and runs the kernel.
> >>> ktrace isn't available until afterwards, when the kernel is running.
> >>>
> >>>> Is ktrace the best "trace suite" for freebsd kernel?
> >>> Kinda depends on what you are doing.  Setting up good logging and
> making
> >>> userland
> >>> interfaces for getting to useful information (cf vmstat, ps, iostat,
> etc)
> >>> is
> >>> more likely to be useful over the longer run.
> >>>
> >>>
> >> What about if I wanna see the interaction between boot process and
> kernel
> >> loading.
> >
> > either you run it under an emulator that allows you to single step it.
> > or you just add a lot of printf() to the boot loader.
> > (some parts are required to fit in small code sizes to adding prints will
> cause overflow..)
> > best to read the docs and then the sources. then it wil become apparent
> to you
> > what you want to find out.
>
> You also have the option of writing Forth modules for the boot-loader. Even
> dropping to the "ok" prompt is enough to give you full access to the
> built-in Forth interpreter. You can query the variables that are set in the
> "environment" (which are different depending whether you've booted via
> pxeboot, cdboot, or other method). You can even do some limited device
> poking and file-io (both read and write).
>
> The benefit of the forth modules is that you can use it to produce the
> necessary debug output whilst avoiding the overflow issue. That is to say,
> that one technique I've used is to add code to the loader to export some
> string or value of interest to a variable in the environment that I would
> then add something like 'echo "debug == $debug"' to loader.rc. Keeps the
> loader small and the human fluff off to the interpreter.
>
> >
> >>
> >>>> What about going through source code .. Is it better to
> >>>> use Combination of Ecllipse/Qemu and FreeBSD Source tree?
> >>> Eclipse is an editor.  If you like it in particular, free free to use
> it,
> >>> otherwise pick something else you'd prefer to use for C code.
>
> I use a combination of vim (as my editor) and CVSweb (URL is in the
> handbook) for historical research as necessary.
>
> Just my "tuppence."
> --
> Devin
>
> >>>
> >>>> Does this method will provide us with someway to see how booting
> process
> >>> invokes
> >>>> the kernel to memory ? Any help will be appreciated.
> >>> You're asking about the process here:
> >>>
> >>>
> >>>
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html
> >>>
> >>> ...?  Frankly, none of these are especially big, start by reviewing the
> >>> source
> >>> code for 'em.
> >>>
> >>>
> >> Yeah. this file provides me with the stages in theoretical way. How
> about
> >> implementing it using qemu to emulate livecd to see what is going on
> boot0.
> >> Do you have an idea about that ?
> >>
> >> Good Luck,
> >>
> >>
> >>> Regards,
> >>> --
> >>> -Chuck
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> freebsd-current_at_freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to "
> freebsd-current-unsubscribe_at_freebsd.org"
> >>
> >
> > _______________________________________________
> > freebsd-hackers_at_freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "
> freebsd-hackers-unsubscribe_at_freebsd.org"
>
> _____________
>
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i) delete the
> message and all copies; (ii) do not disclose, distribute or use the message
> in any manner; and (iii) notify the sender immediately. In addition, please
> be aware that any message addressed to our domain is subject to archiving
> and review by persons other than the intended recipient. Thank you.
> _____________
> _______________________________________________
> freebsd-hackers_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe_at_freebsd.org"
>



-- 
*Mohammed Farrag*
*FreeBSD Contributor*
Received on Mon Apr 11 2011 - 16:08:21 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:13 UTC