Greetings,
Please consider the scenario below:
Since i'm using "-ffunction-sections and -fdata-sections", my segments are put
int (.text.*) and (.data.*) instead of just (.text) and (.data). This results
in arm-elf-size outputs as follows:
When I use 'arm-elf-size -B' I get:
arm-elf-size -B Output/Exe/Bootstrapper.elf
text data bss dec hex filename
18068 0 5508 23576 5c18 Output/Exe/Bootstrapper.elf
When I use 'arm-elf-size -A' I get:
arm-elf-size -A Output/Exe/Bootstrapper.elf
Output/Exe/Bootstrapper.elf :
section size addr
.startup 80 1048576
.text 16892 1048656
.data 1096 2097152
.bss 5508 2098248
.debug_abbrev 22956 0
.debug_info 102031 0
.debug_line 19194 0
.debug_frame 9912 0
.debug_loc 44707 0
.debug_pubnames 8590 0
.debug_aranges 4768 0
.debug_ranges 2104 0
.debug_str 17160 0
.comment 1188 0
Total 256186
Neither is very usefull and this is why :
When trying to optimize the code I need to know how much FLASH and how much RAM
is used.
Using option '-A' I cannot see the .data-sections size so this is useless here.
Using option '-B' I can see how much space is used in each segment, but I have
to manually calculate the used space as in "Flash = .startup + .text + .data"
and "RAM = .data + .bss". The '-B' option is the must usefull one but not very
good as I have to calulate it manually.
My feature request :
Implement a "-C" option that optimizes the output for embedded systems as
described above. This way embedded devs can quickly get an overview of the
resource usage of their devices. This could be extended even further in terms
of usefulness if another option eg "-l SAM7S256.ld" could point to the linker
script. This way arm-elf-size would be able to show the space left on the
device in terms of bytes and or %...
Cheers
RaceMouse
--
Summary: arm-elf-size usefullness
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fink at racemouse dot net
GCC target triplet: arm-elf-size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32491
