[lkml]   [1999]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.

Jakub Jelinek | |
Administrator of SunSITE Czech Republic, MFF, Charles University
UltraLinux | |
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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:53    [W:0.076 / U:0.064 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site