public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: Dan Kegel <dank@kegel.com>, 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)
Date: Wed, 2 Sep 2020 17:19:28 +0200	[thread overview]
Message-ID: <a91c1acf-bae6-0321-ebeb-21719d527a74@hesbynett.no> (raw)
In-Reply-To: <CAPF-yOa0Wj6Yq9rzAbM6qGybmW=uNRiYjvOmPLdCwFpiJnZA3w@mail.gmail.com>

(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
>>
>>
> 


      parent reply	other threads:[~2020-09-02 15: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
2020-09-02 15:19   ` David Brown [this message]

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=a91c1acf-bae6-0321-ebeb-21719d527a74@hesbynett.no \
    --to=david.brown@hesbynett.no \
    --cc=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).