Messages in this thread | | | Date | Sat, 24 Jul 1999 10:10:58 +0200 | From | Jakub Jelinek <> | Subject | Re: bloat and debugging code |
| |
On Fri, Jul 23, 1999 at 09:18:05PM -0700, Zack Weinberg wrote: > > > > Add 32-byte alignment padding for every string, the increased size of > > > struct wait_queue, and the code for the macros themselves, and you can > > > see where the bloat is coming from. > > > > And the point being? It's -CURRENT, ferchrissake. In pretty unstable > > state. Vanilla 2.3.11 has a race in bdflush giving spontaneous reboots. > > 2.3.12-pre1 *seems* to fix it, but something still lurks there. Easily > > removable bloat from debugging is not a problem, IMHO. > > Did I say it was a problem? I'm actually pleased to find the only > reason 2.3 is bigger is debugging. (Makes me want to go hack up ld > though...)
It is not only matter of ld, because the compiler must at least indicate the size of the .rodata strings. With const objects which go into .rodata you have .size, but not with strings. Assembler would have to keep those .L* symbols for .rodata objects and rip them off during the final link after all identical .rodata objects have been merged using some hash table.
Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz Administrator of SunSITE Czech Republic, MFF, Charles University ___________________________________________________________________ UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/ Linux version 2.3.10 on a sparc64 machine (1343.49 BogoMips) ___________________________________________________________________
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |