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

[Senthil Kumar Selvaraj]

Ping!

Regards
Senthil

On Wed, May 27, 2015 at 08:58:22AM +0530, Senthil Kumar Selvaraj wrote:
> 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