lkml.org 
[lkml]   [2002]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] BUG preserve registers
Denis Vlasenko wrote:
>
> On 10 February 2002 07:05, Andrew Morton wrote:
> > Andrew Morton wrote:
> > > I think I'm done with this now.
> >
> > Famous last words. There's a slightly updated version at
> > http://www.zip.com.au/~akpm/linux/2.4/2.4.18-pre9/
> >
> > CONFIG_DEBUG_BUGVEROSE has been retained - it's now used to enable
> > BUG() in a couple of bloaty places. But BUG() now always
> > reports file-and-line.
> >
> > Also, here's the kill-BUG-in-headers patch. With this, the
> > kernel image is in fact a few kbytes smaller than stock
> > 2.4.18-pre9 with CONFIG_DEBUG_BUGVERBOSE=n, and we get full
> > file-and-line and the registers aren't trashed, so everyone's
> > happy.
>
> I downloaded BUG.patch and inline-BUG.patch and compiled 2.4.18-pre9
> bzImage with and without these patches:
>
> 2.4.18-pre9: bzImage 996963 vmlinux 2440880
> 2.4.18-pre9+patches: bzImage 997531 vmlinux 2441182
>
> .config is the same, you may find it below.
> "# CONFIG_DEBUG_BUGVERBOSE is not set"
> Andrew, are these numbers expected?

Pretty much. In adding the patch, you've added six more bytes
to each BUG() call site and numerous filenames. For me, the
kernel came out a little smaller, but for you, it grew a bit. I
wonder why. From a quick test it seems that gcc-3.0.3 and
recent binutils do fold common strings between compilation
units. But I need to double-check that. Maybe it's due to
that somehow.

Of course, for the extra 300 bytes of kernel you've gained
file-and-line info in all the BUG calls.

-
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.068 / U:0.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site