From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from asav21.altibox.net (asav21.altibox.net [109.247.116.8]) by sourceware.org (Postfix) with ESMTPS id D5C7B3857009 for ; Wed, 2 Sep 2020 15:19:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D5C7B3857009 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hesbynett.no Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=david.brown@hesbynett.no Received: from mail.jansenbrown.no (unknown [92.221.34.247]) by asav21.altibox.net (Postfix) with ESMTP id 2D6418018B; Wed, 2 Sep 2020 17:19:28 +0200 (CEST) Received: from [192.168.0.63] (unknown [79.161.10.130]) by mail.jansenbrown.no (Postfix) with ESMTPSA id 45C241FAB20; Wed, 2 Sep 2020 17:19:28 +0200 (CEST) Subject: Re: Variables assigned to ram are increasing elf file size (=> occupying flash) To: Dan Kegel , Rachel Sapir Cc: gcc-help , Rachel Sapir References: From: David Brown Message-ID: Date: Wed, 2 Sep 2020 17:19:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=XdKnMrx5 c=1 sm=1 tr=0 a=+Fy6h7hJ4UJcWgHwdIx3jg==:117 a=+Fy6h7hJ4UJcWgHwdIx3jg==:17 a=IkcTkHD0fZMA:10 a=reM5J-MqmosA:10 a=8LzAatEx0TRF6ZpLZaoA:9 a=QEXdDO2ut3YA:10 X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_BL, RCVD_IN_MSPIKE_L5, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 15:19:34 -0000 (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 > #include > 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 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 >> >> >