Date: Sat, 21 Aug 1999 10:14:39 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: current@FreeBSD.ORG, alpha@FreeBSD.ORG Subject: Re: cc -O broken in -current for Alpha KLDs Message-ID: <Pine.BSF.4.10.9908211014050.72739-100000@salmon.nlsystems.com> In-Reply-To: <14269.25728.498019.956479@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Aug 1999, Andrew Gallatin wrote: > > Doug Rabson writes: > > On Thu, 19 Aug 1999, Andrew Gallatin wrote: > > > > > > > > I do most of my development on alphas & I just turned some local code > > > into a loadable kernel module. It works fine when compiled into the > > > kernel statically, but fails miserably when loaded into an alpha > > > kernel as a module. This alpha is running -current from monday or > > > so. > > > > > > After a day or so of debugging, I decided to run > > > it on an x86 -- it ran just fine. I've narrowed the problem down to > > > one involving optimization and have extracted a simple, reproducable > > > test case. > > > > > > When the test module is loaded without optimization (CFLAGS += -g > > > -O0), it prints the following (which is correct): > > > > It looks like we aren't handling the relocations correctly. When I get a > > chance, I will try to look at it. If you want to have another look, the > > code at fault is probably in alpha/alpha/elf_machdep.c and you can get a > > list of relocations in the module with 'objdump --dynamic-reloc foo.ko'. > > Thanks for the pointer, it was right on the money. It turns out that > at the default optimization level, the objdump output looks like this: > > <...> > 0000000000010ea8 RELATIVE *ABS* > 0000000000010e80 GLOB_DAT Xmit_completes+0x0000000000000028 > 0000000000010e88 GLOB_DAT Xmit_completes+0x0000000000000008 > 0000000000010e90 GLOB_DAT Xmit_completes+0x0000000000000010 > 0000000000010e98 GLOB_DAT Xmit_completes+0x0000000000000018 > 0000000000010ea0 GLOB_DAT Xmit_completes > 0000000000010e70 JMP_SLOT printf > <...> > > I've just committed a patch to alpha/alpha/elf_machdep.c which takes > into account the addends for objects of type R_ALPHA_GLOB_DAT. This > fixes my problem. Should it be MFC'ed? I think it can be MFC'ed right away. There are no dependancies on the rest of the system and its a serious problem. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9908211014050.72739-100000>