Thread overview | ||||||||
---|---|---|---|---|---|---|---|---|
|
September 10, 2001 DOSX big EXE with static array | ||||
---|---|---|---|---|
| ||||
Hello, why do static arrays (or every variable defined as static) generate big EXE files when compiled in DOSX. This example #include <stdio.h> static char adr[1000000]; int main() { printf("&adr[10] = %p\n", adr+10); return 0; } generates a EXE-file of more than 1MB when compiled with sc -mx test.c Without static the resulting EXE is only 30k in size. BTW, the same file (with static) compiled as Win32 console isn't growing with static. I thought that uninitialized static variables could go to an extra segment that is allocated and cleared by the startup code. Regards, Heinz |
September 10, 2001 Re: DOSX big EXE with static array | ||||
---|---|---|---|---|
| ||||
Posted in reply to Heinz Saathoff | It looks like a bug in the linker. I suggest using malloc() for large arrays
as a workaround. -Walter
Heinz Saathoff wrote in message ...
>Hello,
>
>why do static arrays (or every variable defined as static) generate big EXE files when compiled in DOSX. This example
>
>#include <stdio.h>
>
>static
>char adr[1000000];
>
>int main()
>{ printf("&adr[10] = %p\n", adr+10);
> return 0;
>}
>
>
>generates a EXE-file of more than 1MB when compiled with
>
> sc -mx test.c
>
>Without static the resulting EXE is only 30k in size.
>BTW, the same file (with static) compiled as Win32 console isn't growing
>with static.
>
>I thought that uninitialized static variables could go to an extra segment that is allocated and cleared by the startup code.
>
>Regards,
> Heinz
|
September 10, 2001 Re: DOSX big EXE with static array | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | Walter schrieb...
> It looks like a bug in the linker. I suggest using malloc() for large arrays
> as a workaround. -Walter
Already used this as a workaround. But I was astonished when I saw the difference in size between a win-console mode program and a DOSX program here.
Thanks,
Heinz
|
September 10, 2001 Re: DOSX big EXE with static array | ||||
---|---|---|---|---|
| ||||
Posted in reply to Heinz Saathoff |
No linker bug WRT this behavior... the reason consists in the way Windows loads executables: the PE must have, of course, a complete DATA section (initialized data), while for the BSS section (uninitialized data, as that array), only the total size must be known, and is allocated automatically by Windows when the program is loaded.
DOS doesn't do this (well, it actually depends on the DOS
extender and the compiler and linker).
There was a question on DM's web site about WDOSX being able to
run DMC programs (probably Win32 console programs)... it
can't! It misses some functions from Win32 API emulation.
Actually, it can't run even Borland C++ 5.5.1 programs (it could only
run only C programs, not C++). Perhaps someone should update
this on DM site: it's better than "I don't know"... :)
Regards,
Laurentiu
>Walter schrieb...
>> It looks like a bug in the linker. I suggest using malloc() for large arrays
>> as a workaround. -Walter
>
>Already used this as a workaround. But I was astonished when I saw the difference in size between a win-console mode program and a DOSX program here.
>
>Thanks,
> Heinz
|
September 11, 2001 Re: DOSX big EXE with static array | ||||
---|---|---|---|---|
| ||||
Posted in reply to Laurentiu Pancescu | Laurentiu Pancescu schrieb...
> No linker bug WRT this behavior... the reason consists in the way Windows loads executables: the PE must have, of course, a complete DATA section (initialized data), while for the BSS section (uninitialized data, as that array), only the total size must be known, and is allocated automatically by Windows when the program is loaded.
>
> DOS doesn't do this (well, it actually depends on the DOS
> extender and the compiler and linker).
This doesn't explain why the EXE gets big when static is used and small
when not. In both cases the array is an uninitialized memory region that
could go to the BSS. The only difference (for the linker) is that the
static defined array is not visible to other compilation units (internal
linkage).
Disassembling shows that the non static array generates a comm (COMDAT?)
symbol to the linker where the static defined array goes into BSS.
Questions to Walter:
1) Do comdats always generate linkable symbols? If not it should
be possible to place static objects into comdat
2) The space for the public arrays in comdat must also be allocated
and cleared during startup. Where's the difference to BSS?
I would agree to Walter that the problem is in the linker that for some reasons treat the uninitialized BSS linke the initialized DATA segment in DOSX.
Regards,
Heinz
|
September 11, 2001 Re: DOSX big EXE with static array | ||||
---|---|---|---|---|
| ||||
Posted in reply to Heinz Saathoff | Heinz Saathoff wrote in message ... >Disassembling shows that the non static array generates a comm (COMDAT?) >symbol to the linker where the static defined array goes into BSS. >Questions to Walter: >1) Do comdats always generate linkable symbols? If not it should > be possible to place static objects into comdat Yes. >2) The space for the public arrays in comdat must also be allocated > and cleared during startup. Where's the difference to BSS? Uninitialized data goes into BSS, which gets cleared by the startup code. BSS getting explicitly allocated may just be an artifact of how the dos extender was done. I don't know. All the BSS thing is anyway is a way to reduce the size of the executable file, it doesn't reduce the size of it in memory at all. |
Copyright © 1999-2021 by the D Language Foundation