From: Dan Kegel <dank@kegel.com>
To: Rachel Sapir <rachel@akribis-sys.com>
Cc: Rachel Sapir <rachel@agito.co.il>, gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: Variables assigned to ram are increasing elf file size (=> occupying flash)
Date: Wed, 2 Sep 2020 07:19:19 -0700 [thread overview]
Message-ID: <CAPF-yOY_iLkWL3fcW_STS1Q6qHsjbkMw8ieg0xEh6+cayi=Fgw@mail.gmail.com> (raw)
In-Reply-To: <SL2PR01MB2795251A84A086E463F26FCE992F0@SL2PR01MB2795.apcprd01.prod.exchangelabs.com>
[-- 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 --]
next prev parent reply other threads:[~2020-09-02 14:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-01 10:21 Rachel Sapir
2020-09-01 15:41 ` Dan Kegel
[not found] ` <SL2PR01MB2795251A84A086E463F26FCE992F0@SL2PR01MB2795.apcprd01.prod.exchangelabs.com>
2020-09-02 14:19 ` Dan Kegel [this message]
2020-09-02 15:19 ` David Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPF-yOY_iLkWL3fcW_STS1Q6qHsjbkMw8ieg0xEh6+cayi=Fgw@mail.gmail.com' \
--to=dank@kegel.com \
--cc=gcc-help@gcc.gnu.org \
--cc=rachel@agito.co.il \
--cc=rachel@akribis-sys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).