From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by sourceware.org (Postfix) with ESMTPS id 88A4B385782F for ; Tue, 1 Sep 2020 15:41:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 88A4B385782F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kegel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=daniel.r.kegel@gmail.com Received: by mail-ej1-f44.google.com with SMTP id bo3so2298189ejb.11 for ; Tue, 01 Sep 2020 08:41:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sYEkEkX3L6FAhfCEkpDVkXv1Sdd9cio55OmB3yKp/rE=; b=UvZIuTURU8jzYuukCV99G1zCqR3vxGjHtICB6vtxhRh4cA7ls+toQK1B1dX0P4gYll 7u6iXJHkOdf6EtNgSzUBky+/uRolc7EN9gTpSiid9tbG0+cZ+jsjrSS4+ECvkzZK4lmA orhmgTlGMykg6j1xgpEdSiWZ/lSg/p9qn2awd3ppnhQuhwOsuWURaC6LHHnQpJlzJCIk h2E+QavABr4BbJ4SxTHcQxlq/H4GNnYoOniYyMTFHJIiP6DrdtQXcE3bbx+qrS4uw2nt IANw1o+M2bvVmj7SZMlnarD3dLo3gk9ViSHnTIL94YN7LPnYgmEmYW9JyVe8ykP96bsO 6Zpw== X-Gm-Message-State: AOAM531d43GGcMWDKQvJuf9F/AeJmX/PiZMj9z88XguHz7990l7wveDN dW7+gNDTQjXy13DMnZ9gQD41nk2lYKuToLKbzBc= X-Google-Smtp-Source: ABdhPJzjdmab4jQKDCM/2hOYoR633setluGVTCYli87lOVhI7gPrNSFKlC9f8LKeU+X6difx1LaTpXlv45+M823Ti4A= X-Received: by 2002:a17:906:8543:: with SMTP id h3mr1955388ejy.258.1598974916476; Tue, 01 Sep 2020 08:41:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dan Kegel Date: Tue, 1 Sep 2020 08:41:45 -0700 Message-ID: Subject: Re: Variables assigned to ram are increasing elf file size (=> occupying flash) To: Rachel Sapir Cc: gcc-help , Rachel Sapir X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Tue, 01 Sep 2020 15:41:59 -0000 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 > >