Memory Overflow

[Jonathan100]

Hi guys.

In eclipse based Vitis, i got this error:
c:/xilinx/vitis/2020.2/gnu/microblaze/nt/x86_64-oesdk-mingw32/usr/bin/microblaze-xilinx-elf/../../libexec/microblaze-xilinx-elf/gcc/microblaze-xilinx-elf/9.2.0/real-ld.exe: region `microblaze_0_local_memory_ilmb_bram_if_cntlr_Mem_microblaze_0_local_memory_dlmb_bram_if_cntlr_Mem' overflowed by 1235064 bytes

My code sources may oversize the memory of the microblaze in more then 1Mbytes.
What does this error means? remember we are talking here on build and link only.

I tried to erase all of print statement, reduce static variables size (That i aware of) .It reduced to 100kbytes overflow.

How can i inspect the code (20+ .h and .cpp files thousands of lines long)
to see what variables take the most of the memory? is there tool for that?

[salem c]

Microcontrollers tend to have decent code space, but not a lot of data space.
Or maybe not, I guess it depends on the intended use-cases for the controller in question.

You can get all your symbol sizes with nm.

$ nm --defined-only --print-size --demangle a.out
0000000000004010 B __bss_start
0000000000004018 0000000000000001 b completed.8061
0000000000004000 D __data_start
0000000000004000 W data_start
0000000000001230 t deregister_tm_clones
00000000000012a0 t __do_global_dtors_aux
0000000000003d58 d __do_global_dtors_aux_fini_array_entry
00000000000015cb 00000000000000ac T draw_table
00000000000012e9 0000000000000059 T drop_apple
// etc etc

You can see what's allocated to each section with objdump

$ objdump --section-headers a.out

a.out:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .interp       0000001c  0000000000000318  0000000000000318  00000318  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .note.gnu.property 00000020  0000000000000338  0000000000000338  00000338  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .note.gnu.build-id 00000024  0000000000000358  0000000000000358  00000358  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .note.ABI-tag 00000020  000000000000037c  000000000000037c  0000037c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
// etc etc

Read the manual pages on both tools for the gory details and more options to play with.

[Jonathan100]

I work on windows, is it possible here too?

If i only declare static variable but not use it, is it account for the memory?

[salem c]

You're using GNU tools, so you should have them around somewhere.

> If i only declare static variable but not use it, is it account for the memory?
Sure (maybe).
It depends on your options.
There are options to prune out dead code.

--gc-sections
--no-gc-sections
Enable garbage collection of unused input sections. It is ignored on targets that do not support this option. The default behaviour (of not performing this garbage collection) can be
restored by specifying --no-gc-sections on the command line. Note that garbage collection for COFF and PE format targets is supported, but the implementation is currently considered to
be experimental.

--gc-sections decides which input sections are used by examining symbols and relocations. The section containing the entry symbol and all sections containing symbols undefined on the
command-line will be kept, as will sections containing symbols referenced by dynamic objects. Note that when building shared libraries, the linker must assume that any visible symbol is
referenced. Once this initial set of sections has been determined, the linker recursively marks as used any section referenced by their relocations. See --entry, --undefined, and
--gc-keep-exported.

This option can be set when doing a partial link (enabled with option -r). In this case the root of symbols kept must be explicitly specified either by one of the options --entry,
--undefined, or --gc-keep-exported or by a "ENTRY" command in the linker script.

A couple more linker options for you.

--print-memory-usage
Print used size, total size and used size of memory regions created with the MEMORY command. This is useful on embedded targets to have a quick view of amount of free memory. The format
of the output has one headline and one line per region. It is both human readable and easily parsable by tools. Here is an example of an output:

Memory region Used Size Region Size %age Used
ROM: 256 KB 1 MB 25.00%
RAM: 32 B 2 GB 0.00%

-Map=mapfile
Print a link map to the file mapfile. See the description of the -M option, above.

A question would be, did you go from a working system to one that was 1MB too big in a single edit?

[Jonathan100]

No, usually I am working on Zynq processor.
Now I am working on microblaze which is softcore
with considerably less ram

[Jonathan100]

salem c (3595) > where should i add this "--print-memory-usage" ?

in the linker command?

mb-g++ --print-memory-usage

i got an error:

microblaze-xilinx-elf-g++.exe: error: unrecognized command line option '--print-memory-usage'

[JLBorges]

mb-g++ -Wl,--print-memory-usage

Pass an option to the linker https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options