From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117995 invoked by alias); 27 May 2015 03:29:24 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 117912 invoked by uid 89); 27 May 2015 03:29:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_50,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: DVREDG01.corp.atmel.com Received: from nasmtp01.atmel.com (HELO DVREDG01.corp.atmel.com) (192.199.1.245) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 27 May 2015 03:29:09 +0000 Received: from apsmtp01.atmel.com (10.168.254.31) by DVREDG01.corp.atmel.com (10.42.103.30) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 May 2015 21:29:01 -0600 Received: from PENCHT01.corp.atmel.com (10.168.5.161) by apsmtp01.atmel.com (10.168.254.31) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 May 2015 11:28:58 +0800 Received: from atmel.com (10.168.5.13) by cas-ap.atmel.com (10.168.5.161) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 May 2015 11:29:02 +0800 Date: Wed, 27 May 2015 03:29:00 -0000 From: Senthil Kumar Selvaraj To: , Subject: Re: [Patch, tentative] Show output section size contribution from each input file in map file Message-ID: <20150527032821.GA1671@atmel.com> References: <20150520124445.GB1763@atmel.com> <20150527011222.GI14752@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20150527011222.GI14752@bubble.grove.modra.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00255.txt.bz2 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