Re: as memory use for large bss arrays

[Andi Kleen <andi at firstfloor dot org>]

On Fri, Jan 11, 2008 at 04:34:50PM +0100, Andreas Schwab wrote:
> Andi Kleen <andi@firstfloor.org> writes:
> 
> > I made a mistake last night where I accidentially created an (uninitialized)
> > global array in C that was several hundred TB large.  gcc didn't have much
> > trouble with it, but gas seemed to try to put it all into memory. 
> 
> I cannot reproduce that.  Care to provide a test case?

        .type   alloc_bm, @object
        .size   alloc_bm, 4503599627370368
alloc_bm:
        .zero   4503599627370368

On investigation the problem only happens when the output device
is a non seekable file (I saw when running it through icecream which
apparently runs as like that). Try -o /dev/stdout

What then happens is it tries to seek in the output fd which fails:

lseek(3, 4503599627374592, SEEK_SET)    = -1 EINVAL (Invalid argument)
lseek(3, 0, SEEK_CUR)                   = 0
write(2, "dma-alloc.s: ", 13)           = 13
write(2, "Assembler messages:\n", 20)   = 20
write(2, "dma-alloc.s:805: ", 17)       = 17
write(2, "Fatal error: ", 13)           = 13
write(2, "can\'t write x.o: File truncated", 31) = 31
write(2, "\n", 1)                       = 1

and then as goes into an endless loop spewing out

x.s:805: Fatal error: can't close x.o: File truncated
x.s:805: Fatal error: can't close x.o: File truncated
x.s:805: Fatal error: can't close x.o: File truncated
....
en.

which never stops and as grows a little bit on each error 
iteration until it eats all memory.

So I presume it falls back to seeks but the error handling
of that when seeks don't work are brok

Question is why does it even seek for generating BSS?  That is just a number
isn't it?

-Andi