Subject: Re: kgdb's weak symbols vs. gcc 4.1 - msg#00032

Previous Message by Date: click to view message preview

kgdb's weak symbols vs. gcc 4.1

Hi, I stumbled over some issue of kgdb in combination with gcc 4.1 since kernel 2.6.16. The background can be found in [1]. It melts down that the default arch-dependent functions in kernel/kgdb.c got compiled in - and immediately optimised out again. The effect is, of course, lethal. As a workaround I added "CFLAGS_kgdb.o += -fno-unit-at-a-time" to kernel/Makefile, but I'm not sure if this is the preferred solution here. Alternatives might be to move all default arch-stubs into a separate object file, thus giving the linker the chance again to handle them, or to use #ifndef KGDB_HAVE_ARCH_xxx constructs. Jan PS: Please CC me on reply. [1] http://gcc.gnu.org/ml/gcc-help/2006-05/msg00202.html signature.asc Description: OpenPGP digital signature

Next Message by Date: click to view message preview

Re: [PATCH]: linux-2.6 x86_64 kgdb issue

On Fri, May 19, 2006 at 10:15:39PM +0400, Vladimir A. Barinov wrote: > The stack exception occurs always at the same step during debugging in > kgdb_mem2hex(). > I've attached patch that fixes this issue. Could you please review, is > this patch appropriate > to the problem? > > Vladimir > --- kgdb.c.orig 2006-05-19 19:41:22.000000000 +0400 > +++ /home/volodia/work/Irwindale/linux-2.6.16/arch/x86_64/kernel/kgdb.c > 2006-05-19 21:26:14.000000000 +0400 > @@ -421,8 +421,8 @@ static int kgdb_notify(struct notifier_b > struct die_args *args = ptr; > struct pt_regs *regs = args->regs; > > - if (cmd == DIE_PAGE_FAULT_NO_CONTEXT && atomic_read(&debugger_active) > - && kgdb_may_fault) { > + if ((cmd == DIE_PAGE_FAULT_NO_CONTEXT || cmd == DIE_TRAP) > + && atomic_read(&debugger_active) && kgdb_may_fault) { > kgdb_fault_longjmp(kgdb_fault_jmp_regs); > return NOTIFY_STOP; > /* CPU roundup? */ I believe this to be OK, but I need to think about it a bit more. Thanks! -- Tom Rini ------------------------------------------------------- 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

Previous Message by Thread: click to view message preview

kgdb's weak symbols vs. gcc 4.1

Hi, I stumbled over some issue of kgdb in combination with gcc 4.1 since kernel 2.6.16. The background can be found in [1]. It melts down that the default arch-dependent functions in kernel/kgdb.c got compiled in - and immediately optimised out again. The effect is, of course, lethal. As a workaround I added "CFLAGS_kgdb.o += -fno-unit-at-a-time" to kernel/Makefile, but I'm not sure if this is the preferred solution here. Alternatives might be to move all default arch-stubs into a separate object file, thus giving the linker the chance again to handle them, or to use #ifndef KGDB_HAVE_ARCH_xxx constructs. Jan PS: Please CC me on reply. [1] http://gcc.gnu.org/ml/gcc-help/2006-05/msg00202.html signature.asc Description: OpenPGP digital signature

Next Message by Thread: click to view message preview

Re: kgdb's weak symbols vs. gcc 4.1

Tom Rini wrote: On Mon, May 22, 2006 at 09:24:32PM +0200, Jan Kiszka wrote: Hi, I stumbled over some issue of kgdb in combination with gcc 4.1 since kernel 2.6.16. The background can be found in [1]. It melts down that the default arch-dependent functions in kernel/kgdb.c got compiled in - and immediately optimised out again. The effect is, of course, lethal. As a workaround I added "CFLAGS_kgdb.o += -fno-unit-at-a-time" to kernel/Makefile, but I'm not sure if this is the preferred solution here. Alternatives might be to move all default arch-stubs into a separate object file, thus giving the linker the chance again to handle them, or to use #ifndef KGDB_HAVE_ARCH_xxx constructs. This sounds kind of like a gcc bug. If you have the message from Florian Weimer could you please bounce me a copy? I'd like to verify that the correct solution to this problem is roughly: 1) kgdb.h includes weak declarations 2) kernel/kgdb.c does not provide any copy of the function 3) arch/$ARCH/kernel/kgdb.c may or may not provide the function and finally 4) There's a way to get the desired behavior out of both gcc-4.1 and gcc-3.3 at least. Thanks! I think you also need to provide a library of weak functions, it just needs to be in a different *.c so gcc doesn't see it and conclude that it can drop it. I.e. the linker needs to see both the real arch version and the weak version. One wonders what gcc would do if the weak module was not empty... -- George Anzinger george@xxxxxxxxxxxxxxxxxxx HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ ------------------------------------------------------- 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