On Tue, 2006-09-05 at 16:00 +0530, Amit S. Kale wrote:
> On Wednesday 30 August 2006 07:44, Piet Delaney wrote:
> > If your interested in the changes to compile the complete
> > kernel -O0 let me know. I'm checking it in here for both
> > kgdb and kdump use in the future. I also converted static
> > inlines to just static functions via CPP macros to get clear
> > back traces. At NetZen/UNM I used a gcc option to force removing
> > inline functions; eventually that approach might be a better solution.
>
> I am certainly interested. -O0 implies better single step and backtraces. I
> had used it several years ago, though maintaining it with kernel versions
> became too difficult. Could you post a patch to present kgdb to compile a
> kernel with -O0?
Ok, I'll try using a git clone on Tom's vger workspace.
Used:
git clone
git://www.kernel.org/pub/scm/linux/kernel/git/trini/linux-2.6-kgdb-for_akpm.git
and
git clone
git://www.kernel.org/pub/scm/linux/kernel/git/trini/linux-2.6-kgdb-master.git
works great.
Want the:
"static inline" --> "static" macros
that I use with the TCP stack also? Sometime compiling the kernel
-O0 make it more difficult to reproduce a bug and it's better to
compile the kernel -O2 and just a sub-set of the kernel, like the
tcp/ip stack, -O0 or -O1 but removed the inlines to make the stack
sensible. With inlines 60% of the TCP functions are invisible. I also
modified the internet Makefiles to compile the networking code -O0
even if the kernel is -O2 for KGDB and KEXEC kernels. Perhaps a new
config variable CONFIG_KDUMP would be better than CONFIG_KEXEC. For
example in my /linux-4/net/Makefile I added:
ifdef CONFIG_KGDB
CFLAGS += -gdwarf-2 -O0
else
ifdef CONFIG_KEXEC
CFLAGS += -gdwarf-2 -O0
endif
endif
BTW, was my KGDB_DEBUG() macro worthy of integration? If so I could
add a bit more usage, like in the ethernet path that I did a few months
ago. If we sent less time helping others on resolving easy problems
we could focus on more interesting problems like 'crash' and kdump
compatibility and additionally kernel cleanups. It seems there are
a some kernel variables that are bogus and is distracting while
using kgdb to scan the landscape. For example in the ide disk
subsystem I notices that *hwgroup->drive->queue->flush_rq is bogus.
Unfortunately I can't attach the back-trace and display graph
as I did in mail a minute ago. If anyone is interested let me
know and I'll mail them two you. Any chance we could get the
max email size increased by a 10x or 100x at lists.sourceforge.net?
100KB is very small. It would be nice to be able to exchange
ddd displays.
I think some guys would likely prefer to leave stuff in an unexpected
state for Performance reasons, so conditionally "fixing" these for
kernels expected to be looked at with a debugger may be a preferable
solution. Myself I don't see the extra cycle or two in leaving things
in crystal clear state prohibitively expensive.
-piet
> Thanks.
> -Amit
--
Piet Delaney
BlueLane Teck
W: (408) 200-5256; [EMAIL PROTECTED]
H: (408) 243-8872; [EMAIL PROTECTED]
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Kgdb-bugreport mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
