This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Patch, tentative] Show output section size contribution from each input file in map file
- From: Senthil Kumar Selvaraj <senthil_kumar dot selvaraj at atmel dot com>
- To: <binutils at sourceware dot org>, <nickc at redhat dot com>
- Date: Wed, 27 May 2015 08:58:22 +0530
- Subject: Re: [Patch, tentative] Show output section size contribution from each input file in map file
- Authentication-results: sourceware.org; auth=none
- References: <20150520124445 dot GB1763 at atmel dot com> <20150527011222 dot GI14752 at bubble dot grove dot modra dot org>
On Wed, May 27, 2015 at 10:42:22AM +0930, Alan Modra wrote:
> On Wed, May 20, 2015 at 06:14:46PM +0530, Senthil Kumar Selvaraj wrote:
> > This very rough patch adds extra information to the map file to show
> > how much each input file contributed to output sections in the output
> > file. While this information can already by computed by
> > grepping/summing existing map file output, this patch makes that
> > unnecessary - it groups by input bfd.
> >
> > The primary motivation is to help embedded developers (or anyone who is
> > paranoid about code size) quickly figure out where most of the code/data
> > is coming from.
>
> Sorry, I don't see this as useful at all. For people who don't want
> the collected information, it is just clutter. Teach your users about
> grep instead..
For trivial, straightforward compile-linkss, I agree it doesn't add value.
Where it gets interesting is when code is compiled and linked with
-ffunction-sections/-fdata-sections or with custom section names, which
are then grouped into appropriate output sections in the (perhaps custom)
linker script.
For example, for this source file
$ cat test.c
volatile int x;
int y;
void foo()
{
y++;
}
void bar()
{
x++;
}
int main()
{
bar();
return x;
}
When compiled with
$ ~/avr/install/bin/avr-gcc -o test.o -c test.c -ffunction-sections -fdata-sections -mmcu=atmega1280
$ ~/avr/install/bin/avr-gcc -o test test.o -Wl,--gc-sections -Wl,-Map=test.map -mmcu=atmega1280
Running grep 'test.o' test.map
.text 0x0000000000000000 0x0 test.o
.data 0x0000000000000000 0x0 test.o
.bss 0x0000000000000000 0x0 test.o
.text.foo 0x0000000000000000 0x22 test.o
LOAD test.o
.text.bar 0x000000000000010c 0x22 test.o
.text.main 0x000000000000012e 0x1a test.o
COMMON 0x0000000000800200 0x4 test.o
.comment 0x0000000000000000 0x29 test.o
whereas the map file (after my patch), has this
Input files and contributions to output file.
/home/saaadhu/avr/install/lib/gcc/avr/6.0.0/../../../../avr/lib/avr51/crtatmega1280.o
.text 0xfc
.note.gnu.avr.deviceinfo
0x40
.debug_info 0xbbc
.debug_abbrev 0xb1a
.debug_line 0x1d
.debug_str 0x3e9
test.o
.text 0x3c
.bss 0x4
.comment 0x29
_exit.o
.text 0x4
.debug_aranges 0x20
.debug_info 0x93
.debug_abbrev 0x14
.debug_line 0x70
_clear_bss.o
.text 0x10
.debug_aranges 0x20
.debug_info 0x93
.debug_abbrev 0x14
.debug_line 0x94
test.o
To arrive at that, you'd have to skip the initial few lines (from the discarded sections output), figure out
the input->output section mapping for .text.{bar,main} and then add up the sizes.
You'd also have to repeat this for *every* object file involved in the link, remembering to include crt/startup,
archive members etc..
I'm not saying it can't be done otherwise - just that the linker already has all this information that might
prove useful for code size analysis, so why not make it show that? Would making it optional via a command line flag work?
Regards
Senthil
>
> $ gcc -o hello hello.o -Wl,-Map,hello.map
> $ grep hello.o hello.map
> 0x0000000000000000 0x0 hello.o
> LOAD hello.o
> .text 0x00000000004004d6 0x46 hello.o
> .rodata 0x00000000004005a4 0x6 hello.o
> .eh_frame 0x0000000000400658 0x40 hello.o
> .data 0x0000000000600928 0x0 hello.o
> .bss 0x0000000000600929 0x0 hello.o
> .comment 0x000000000000001a 0x1b hello.o
>
> --
> Alan Modra
> Australia Development Lab, IBM