Re: [PATCH] mkelf32: Correct sh_link

["Christoph Egger" <Christoph.Egger@amd.com>]

On Thursday 04 January 2007 10:58, Keir Fraser wrote:
> On 4/1/07 08:30, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
> >> Indeed, and that's what we're doing currently. But this is problematic
> >> as it's very easy for other files to get lost, not be handed over etc.
> >> and working backwards to the right version is very rarely feasible...
> >> Thus we'd like to have a single binary (or more importantly dump!) that
> >> has everything in place.
> >
> > Further, when you boot on a serial console how do you connect gdb
> > over a serial console? You can't use a serial console for two things
> > concurrently. Then a xen-kernel debugger is useful. And yeah, that needs
> > standard symtabs and strtabs.
> > And with a kernel debugger, you don't need to worry about what John
> > pointed out.
>
> Gdbstub and console can share a serial port. When gdbstub is entered then
> the gdbstub steals the serial port. Console messages are then wrapped as
> gdb messages. Given that this setup works and requires minimal code in Xen,
> I have no interest in accepting an in-kernel debugger into the tree.

What about xen/common/keyhandler.c ? Isn't this a very tiny
in-kernel debugger? If YOU are fine with gdb, why is it there?
And it ALWAYS gets compiled in.

We already have gdb, xentrace, xencrash, loglevels and more. Nonetheless,
many developers still add/remove tons of printk()'s for debugging purpose.

I count this as a sign, that there is a demand for better debugging 
facilities. gdb is a very powerful general purpose debugger.
So the core question is, what is really needed and what not.

_Some_ examples to think about:
Is a command line useful? Should it be possible to lookup symbols
for its addresses? Is it useful to reprint xen messages?
Is it better to put lots of printk() to figure out which virtual cpus and 
interrupts are mapped to which physical ones or just tell the debugger "show 
me this" ?