Messages in this thread Patch in this message | | | Date | Thu, 15 Jan 2004 08:38:24 -0700 | From | Tom Rini <> | Subject | Re: [PATCH][RFC] 2.6 && module + -g && kernel w/o -g |
| |
On Thu, Jan 15, 2004 at 10:00:11AM +1100, Rusty Russell wrote:
> In message <20040114210937.GA983@stop.crashing.org> you write: > > Okay. I've been looking at stock 2.6.1 noticed that the fix for this > > issue that Rusty proposed, and that ultimately made it into 2.6.1-rc3 > > (or so) is not correct. The problem is that we do: > > > > err = module_frob_arch_sections(hdr, sechdrs, secstrings, mod); > > /* Which goes over every .debug section and can take _ages_ on something > > * like ipv6 */ > > Right. So the arch-specific module_frob_arch_sections() can be slow. > Logically, the fix should be in those module_frob_arch_sections(), not > in the generic code.
So it was right the first time, OK. :)
> > + /* If we find any debug RELAs, frob these away now. */ > > + if (sechdrs[i].sh_type == SHT_RELA && > > + (strstr(secstrings+sechdrs[i].sh_name, ".debug") > > + != 0)) > > + sechdrs[i].sh_type = SHT_NULL; > > + > > Doesn't cover SHT_REL, and I really dislike name matches: they've bitten > us before. > > Really, I prefer the arch-specific optimization.
FWIW, this isn't an optimization, taking 12 minutes to load the ipv6 module is a bug. :)
Andrew, can you please apply the following patch? Thanks. --- 1.10/arch/ppc/kernel/module.c Fri Sep 12 09:26:52 2003 +++ edited/arch/ppc/kernel/module.c Thu Jan 15 08:35:40 2004 @@ -88,6 +88,10 @@ != is_init) continue; + /* We don't want to look at debug sections. */ + if (strstr(secstrings + sechdrs[i].sh_name, ".debug") != 0) + continue; + if (sechdrs[i].sh_type == SHT_RELA) { DEBUGP("Found relocations in section %u\n", i); DEBUGP("Ptr: %p. Number: %u\n", -- Tom Rini http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |