[ECOS] strange size issue (i386 vs ARM)

[ECOS] strange size issue (i386 vs ARM)

[Mandeep Sandhu]

Hi Guys,

I have this strange size issue with my app. I was testing my app with
the Linux Synthetic target and things work fine. The app does not
utilize any hardware specific feature, rather just relies on the
availability of 2 network interfaces to do its job (it's lwIP 1.3.1
from Simon).

Now, I want to finally run this app on my AT91SAM7X512 based board. So
I did a size comparison to see if it'll fit in the boards memory
(128KB).

I compiled my app with ecos configured for the at91sam7xek target.

$ arm-eabi-size myapp
   text	   data	    bss	    dec	    hex	filename
 127168	   5940	  45092	 178200	  2b818	myapp

From this it seems bss + data will fit fine in the 128KB of RAM that I
have on the board.

Look at the size output for the _same_ app compiled with the Linux
Synthetic target:

$ i386-elf-size myapp
   text	   data	    bss	    dec	    hex	filename
 103690	   7328	8381268	8492286	 8194fe	myapp

The text size of the ARM binary (~127KB) is understandably larger than
the i386 one (~102 KB).

But how come the data+bss value is so different!?!? The i386 one is
more than 8MB!

Is this expected? I'm still googling to find the answer.

Thanks,
-mandeep

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] strange size issue (i386 vs ARM)

[Simon Kallweit]

Mandeep Sandhu wrote:
> Hi Guys,
> 
> I have this strange size issue with my app. I was testing my app with
> the Linux Synthetic target and things work fine. The app does not
> utilize any hardware specific feature, rather just relies on the
> availability of 2 network interfaces to do its job (it's lwIP 1.3.1
> from Simon).
> 
> Now, I want to finally run this app on my AT91SAM7X512 based board. So
> I did a size comparison to see if it'll fit in the boards memory
> (128KB).
> 
> I compiled my app with ecos configured for the at91sam7xek target.
> 
> $ arm-eabi-size myapp
>    text	   data	    bss	    dec	    hex	filename
>  127168	   5940	  45092	 178200	  2b818	myapp
> 
> From this it seems bss + data will fit fine in the 128KB of RAM that I
> have on the board.
> 
> Look at the size output for the _same_ app compiled with the Linux
> Synthetic target:
> 
> $ i386-elf-size myapp
>    text	   data	    bss	    dec	    hex	filename
>  103690	   7328	8381268	8492286	 8194fe	myapp
> 
> The text size of the ARM binary (~127KB) is understandably larger than
> the i386 one (~102 KB).
> 
> But how come the data+bss value is so different!?!? The i386 one is
> more than 8MB!
> 
> Is this expected? I'm still googling to find the answer.

Use objdump -t [filename] to get finer grained information where your 
memory is used. Synth for example uses bigger stacks. But I don't quite 
get myself where all that bss memory is going :)

May someone enlighten us?

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] strange size issue (i386 vs ARM)

[Bart Veer]

>>>>> "Mandeep" == Mandeep Sandhu <mandeepsandhu.chd@gmail.com> 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

Re: [ECOS] strange size issue (i386 vs ARM)

[Mandeep Sandhu]

On Thu, Oct 1, 2009 at 7:56 PM, Bart Veer <bartv@ecoscentric.com> wrote:
>>>>>> "Mandeep" == Mandeep Sandhu <mandeepsandhu.chd@gmail.com> 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.

Thanks Bart. This explains it. It's not an issue for me, was just
curious to know.

Regards,
-mandeep

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