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

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...)  If it doesn't, then removing the
> 'const' seems like the easiest trick to work around this compiler
> pessimization (yes, I can see why the compiler writers argued that
> sticking things in .rodata adds a bit more security against errant code
> accidentally trying to corrupt the buffer; but as the buffer shouldn't
> be escaping, it's already undefined behavior for such code to happen).
It actually also happens for server/plugins.c.

I assumed that filter/nozero got somehow statically linked into the server
(which does not really make sense), so it would have been the same instance of
the problem. Then I forgot to confirm this afterwards.
> diff --git i/filters/nozero/nozero.c w/filters/nozero/nozero.c
> index 16ec710b..21863707 100644
> --- i/filters/nozero/nozero.c
> +++ w/filters/nozero/nozero.c
> ...
Nope, same thing.


Thomas

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).

The fix is in git now.

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

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