From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17493 invoked by alias); 1 Oct 2009 14:26:50 -0000 Received: (qmail 17478 invoked by uid 22791); 1 Oct 2009 14:26:49 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Oct 2009 14:26:38 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 70EA1151B2C6; Thu, 1 Oct 2009 15:26:36 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vB7zW0qHV0TW; Thu, 1 Oct 2009 15:26:31 +0100 (BST) Date: Thu, 01 Oct 2009 14:26:00 -0000 Message-Id: From: Bart Veer To: Mandeep Sandhu CC: ecos-discuss@ecos.sourceware.org In-reply-to: (message from Mandeep Sandhu on Thu, 1 Oct 2009 18:40:14 +0530) References: Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] strange size issue (i386 vs ARM) X-SW-Source: 2009-10/txt/msg00004.txt.bz2 >>>>> "Mandeep" == Mandeep Sandhu writes: Mandeep> Look at the size output for the _same_ app compiled with Mandeep> the Linux Synthetic target: Mandeep> $ i386-elf-size myapp Mandeep> text data bss dec hex filename Mandeep> 103690 7328 8381268 8492286 8194fe myapp Mandeep> The text size of the ARM binary (~127KB) is Mandeep> understandably larger than the i386 one (~102 KB). Mandeep> But how come the data+bss value is so different!?!? The Mandeep> i386 one is more than 8MB! Mandeep> Is this expected? I'm still googling to find the answer. On real embedded targets the memory is physical. Not so on the synthetic target. Somehow or other the executable's ELF header info must tell the Linux OS to allocate 8MB of memory for the emulated target's RAM. Without that things like malloc() would not work, at least not without playing nasty games with mmap() at run-time. The easiest way to make things work is to make it seem like data+bss occupy all of 8MB, irrespective of the application's actual static data requirements. The surplus over 8MB reported by size is likely to be const data and the like which the linker script places in the read-only code region. This could probably be fixed if it was really necessary, but it would be non-trivial and I don't recall anybody reporting the issue in the past. Generally memory usage on the synthetic target will not give an accurate indication of memory usage on real targets because of the need for much larger stack sizes etc. - I won't go into all the unpleasant details. Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. >>>> Visit us at ESC-UK http://www.embedded.co.uk <<<< >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<< -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss