[Patch, tentative] Show output section size contribution from each input file in map file

[Senthil Kumar Selvaraj]

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