Libguestfs - Jul 2019 - Re: [nbdkit] [filter/nozero] large binary size with GCC 9

On Fri, 2019-07-05T08:48-0500, Eric Blake wrote:
> On 7/5/19 8:21 AM, Thomas Weißschuh wrote:
> > On Fri, 2019-07-05T08:04-0500, Eric Blake wrote:
> >> On 7/4/19 1:38 PM, Thomas Weißschuh wrote:
> >>> In filter/nozero a 64M large, static, zeroed, read-only array
is declared.
> >>> The new behavior of GCC puts this array as-is into the binary
inflating the
> >>> size by a factor of around 10000.
> >>
> >> Odd that you are only seeing this for the nozero filter, since we
also
> >> have the same sort of buffer in server/plugins.c.  Oh, I see a
> >> difference between the two - one is function-local, the other is
> >> file-local.  Does this patch make a difference? (I need to fire up
a
> >> rawhide VM to test it myself...)
> 
> Thanks for your fast reply - you did beat me in getting my rawhide VM
> running.
> 
> > It actually also happens for server/plugins.c.
> 
> Good to know. So the fix is indeed removing 'const', rather than
> reducing scope (although I might as well reduce scope while at it, for
> consistency).
Does this not mean, the 64M are zeroed on every loop iteration in every call to
these functions?
(Probably also depends on compiler optimizations)

Maybe this will have some performance impact, or does it not matter with these
functions?

Maybe the
> The fix is in git now.
Thanks!


Thomas

On 7/5/19 9:52 AM, Thomas Weißschuh wrote:
>> Good to know. So the fix is indeed removing 'const', rather
than
>> reducing scope (although I might as well reduce scope while at it, for
>> consistency).
> 
> Does this not mean, the 64M are zeroed on every loop iteration in every
call to
> these functions?
No. static variables are guaranteed by the C standard to start life
pre-initialized (where that initialization is guaranteed to be all
zeroes if there is no explicit initializer), and that pre-initialization
is NOT performed during each call to the function (the compiler may
delay the initialization to the first function call, if that is cheaper
than always initializing the storage even if the function doesn't get
called, but the effect is the same).
> (Probably also depends on compiler optimizations)
Any compiler that initializes a static variable more than once is buggy.
> 
> Maybe this will have some performance impact, or does it not matter with
these
> functions?
No, there should be no performance change.  If there were, that's an
even more serious bug in gcc.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

On Fri, 2019-07-05T10:02-0500, Eric Blake wrote:
> On 7/5/19 9:52 AM, Thomas Weißschuh wrote:
> 
> >> Good to know. So the fix is indeed removing 'const',
rather than
> >> reducing scope (although I might as well reduce scope while at it,
for
> >> consistency).
> > 
> > Does this not mean, the 64M are zeroed on every loop iteration in
every call to
> > these functions?
> 
> No. static variables are guaranteed by the C standard to start life
> pre-initialized (where that initialization is guaranteed to be all
> zeroes if there is no explicit initializer), and that pre-initialization
> is NOT performed during each call to the function (the compiler may
> delay the initialization to the first function call, if that is cheaper
> than always initializing the storage even if the function doesn't get
> called, but the effect is the same).
Ah, yes I forgot the 'static'. Thanks for the clarification.
> > (Probably also depends on compiler optimizations)
> 
> Any compiler that initializes a static variable more than once is buggy.
> 
> > 
> > Maybe this will have some performance impact, or does it not matter
with these
> > functions?
> 
> No, there should be no performance change.  If there were, that's an
> even more serious bug in gcc.
Yep, my bad.

Thanks again,
Thomas