Variables assigned to ram are increasing elf file size (=> occupying flash)

Variables assigned to ram are increasing elf file size (=> occupying flash)

[Rachel Sapir]

Hello,

I noticed that when I increase array sizes (I have some very big arrays)
the .elf file is increased by the same size. Since the elf file is saved to
the flash, it occupies flash area unnecessarily.

Is there a way to prevent this from happening?

Best regards,
Rachel

Re: Variables assigned to ram are increasing elf file size (=> occupying flash)

[Dan Kegel]

Unless they're initialized, the arrays should be in BSS, which shouldn't be
in the elf nor stored to flash (since it's all zero, and should be cleared
on startup).

Since you didn't include a test case, here's a tiny example:

dank@thinky:~$ cat foo.c
#include <stdio.h>
#include <stdlib.h>
int blarg[500000];

int main(int argc, char **argv)
{
   int i = atoi(argv[1]);
   int j = atoi(argv[2]);
   blarg[i] = 7;
   printf("blarg[%d] == %d\n", j, j);
   return 0;
}
dank@thinky:~$ gcc -O2 foo.c
dank@thinky:~$ size a.out
   text   data    bss    dec    hex filename
   1783    608 2000032 2002423 1e8df7 a.out
dank@thinky:~$ ls -l a.out
-rwxrwxr-x 1 dank dank 16768 Sep  1 08:39 a.out

Note the small size of a.out.
- Dan

On Tue, Sep 1, 2020 at 3:21 AM Rachel Sapir <rachel@agito.co.il> wrote:

> Hello,
>
> I noticed that when I increase array sizes (I have some very big arrays)
> the .elf file is increased by the same size. Since the elf file is saved to
> the flash, it occupies flash area unnecessarily.
>
> Is there a way to prevent this from happening?
>
> Best regards,
> Rachel
>
>

Re: Variables assigned to ram are increasing elf file size (=> occupying flash)

[Dan Kegel]

[-- Attachment #1: Type: text/plain, Size: 4612 bytes --]

If you're doing embedded development, you may need to go under the hood a
bit.  It's hard to say without knowing your tool chain and without a
minimal test case.

https://interrupt.memfault.com/blog/how-to-write-linker-scripts-for-firmware
may be illuminating...

Good luck!
- Dan

Rachel Sapir <rachel@akribis-sys.com> schrieb am Mi., 2. Sept. 2020, 02:44:

> Hello Dan!
>
>
>
> Thank you very much for your reply.
>
>
>
> However, I am still confused.
>
>
>
> When I look at the size of my elf file it looks like this:
>
>
>
>    text       data        bss        dec        hex    filename
>
> 638774       6184    4249936    4894894    4ab0ae    MAS02.elf
>
>
>
> So, indeed the bss section is the largest. If I look at the size of the
> elf file it is 7,789,044 bytes, which I guess includes not only the
> sections, but also some other parts of the format. Still, more than 10
> times larger than text + data.
>
>
>
> Now I take one array, that is just a global long variable and change its
> size from 1001 to 100001. This means adding 99000 * 4 = 396000 bytes to bss.
>
>
>
> Now the size looks like this:
>
>
>
>    text       data        bss        dec        hex    filename
>
> 638774       6184    5298512    5943470    5ab0ae    MAS02.elf
>
>
>
> The bss section is 1048576 larger. This is the first surprise to me, since
> it is 2.5 times what I would expect. Not even a round factor that I could
> try to explain.
>
>
>
> The size of the file on the disk is now 7,789,044 bytes. So the size of
> the elf looks like it was not affected by this change.
>
>
>
> When I change the size of several very large arrays, the size file looks
> like this:
>
>
>
>    text       data        bss        dec        hex    filename
>
> 638710       6184    8444240    9089134    8ab06e    MAS02.elf
>
>
>
> Again, only the bss is larger.
>
>
>
> But the size of the elf file is: 11,983,348 bytes. It is significantly
> larger.
>
>
>
> Do you have any idea why?
>
>
>
> Now I tried another thing. I thought this may be related to the fact that
> the large array I am increasing is a two dimensional array (I know, I’m
> grasping at straws and theorizing in crazy ways). I increased another two
> dimensional array, by another random size change, and my file size looked
> like this:
>
>
>
>    text       data        bss        dec        hex    filename
>
> 638710       6184    5298512    5943406    5ab06e    MAS02.elf
>
>
>
> The bss is just the same, to the byte, like the time I changed the one
> dimension array. But now the size of the elf file is 11,983,348 bytes,
> Exactly the same as when changing several other two dimensional arrays.
> This is very very weird. And I swear I am refreshing files and folders and
> looking at the time they were modified.
>
>
>
> Even if you can't help, at least writing it down may help. (but of course
> help will be better 😊)
>
>
>
> Thanks again,
>
> Rachel
>
>
>
>
>
>
>
>
>
>
>
> *From:* Dan Kegel <dank@kegel.com>
> *Sent:* Tuesday, September 1, 2020 6:42 PM
> *To:* Rachel Sapir‏ <rachel@agito.co.il>
> *Cc:* gcc-help‏ <gcc-help@gcc.gnu.org>; Rachel Sapir‏ <
> rachel@akribis-sys.com>
> *Subject:* Re: Variables assigned to ram are increasing elf file size (=>
> occupying flash)
>
>
>
> Unless they're initialized, the arrays should be in BSS, which shouldn't
> be in the elf nor stored to flash (since it's all zero, and should be
> cleared on startup).
>
>
>
> Since you didn't include a test case, here's a tiny example:
>
>
>
> dank@thinky:~$ cat foo.c
> #include <stdio.h>
> #include <stdlib.h>
> int blarg[500000];
>
> int main(int argc, char **argv)
> {
>    int i = atoi(argv[1]);
>    int j = atoi(argv[2]);
>    blarg[i] = 7;
>    printf("blarg[%d] == %d\n", j, j);
>    return 0;
> }
> dank@thinky:~$ gcc -O2 foo.c
> dank@thinky:~$ size a.out
>    text   data    bss    dec    hex filename
>    1783    608 2000032 2002423 1e8df7 a.out
> dank@thinky:~$ ls -l a.out
> -rwxrwxr-x 1 dank dank 16768 Sep  1 08:39 a.out
>
>
>
> Note the small size of a.out.
>
> - Dan
>
>
>
> On Tue, Sep 1, 2020 at 3:21 AM Rachel Sapir <rachel@agito.co.il> wrote:
>
> Hello,
>
> I noticed that when I increase array sizes (I have some very big arrays)
> the .elf file is increased by the same size. Since the elf file is saved to
> the flash, it occupies flash area unnecessarily.
>
> Is there a way to prevent this from happening?
>
> Best regards,
> Rachel
>
>

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 18673 bytes --]

[-- Attachment #3: image001.png --]
[-- Type: image/png, Size: 18673 bytes --]

Re: Variables assigned to ram are increasing elf file size (=> occupying flash)

[David Brown]

(This is for the OP's benefit - I suspect that you, Dan, know this already.)

It's also important to remember that the elf file is not stored in flash
(assuming we are talking about a small embedded system here, rather than
an embedded Linux system or something).  The elf file typically contains
a huge amount of extra information such as debugging data in addition to
the flash image.  It's only the .text and .data sections (and perhaps
some others such as vectors or other flash sections, depending on the
linker setup) that actually take space in the flash.  The .bss section
takes no space in flash.

David


On 01/09/2020 17:41, Dan Kegel wrote:
> Unless they're initialized, the arrays should be in BSS, which shouldn't be
> in the elf nor stored to flash (since it's all zero, and should be cleared
> on startup).
> 
> Since you didn't include a test case, here's a tiny example:
> 
> dank@thinky:~$ cat foo.c
> #include <stdio.h>
> #include <stdlib.h>
> int blarg[500000];
> 
> int main(int argc, char **argv)
> {
>    int i = atoi(argv[1]);
>    int j = atoi(argv[2]);
>    blarg[i] = 7;
>    printf("blarg[%d] == %d\n", j, j);
>    return 0;
> }
> dank@thinky:~$ gcc -O2 foo.c
> dank@thinky:~$ size a.out
>    text   data    bss    dec    hex filename
>    1783    608 2000032 2002423 1e8df7 a.out
> dank@thinky:~$ ls -l a.out
> -rwxrwxr-x 1 dank dank 16768 Sep  1 08:39 a.out
> 
> Note the small size of a.out.
> - Dan
> 
> On Tue, Sep 1, 2020 at 3:21 AM Rachel Sapir <rachel@agito.co.il> wrote:
> 
>> Hello,
>>
>> I noticed that when I increase array sizes (I have some very big arrays)
>> the .elf file is increased by the same size. Since the elf file is saved to
>> the flash, it occupies flash area unnecessarily.
>>
>> Is there a way to prevent this from happening?
>>
>> Best regards,
>> Rachel
>>
>>
>