From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44730 invoked by alias); 8 Jun 2015 06:00:45 -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 44719 invoked by uid 89); 8 Jun 2015 06:00:44 -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; Mon, 08 Jun 2015 06:00:41 +0000 Received: from apsmtp01.atmel.com (10.168.254.30) by DVREDG01.corp.atmel.com (10.42.103.30) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 8 Jun 2015 00:00:37 -0600 Received: from PENCHT02.corp.atmel.com (10.168.5.162) by apsmtp01.corp.atmel.com (10.168.254.30) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 8 Jun 2015 14:00:55 +0800 Received: from atmel.com (10.168.5.13) by cas-ap.atmel.com (10.168.5.162) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 8 Jun 2015 14:00:31 +0800 Date: Mon, 08 Jun 2015 06:00: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: <20150608055956.GA4788@atmel.com> References: <20150520124445.GB1763@atmel.com> <20150527011222.GI14752@bubble.grove.modra.org> <20150527032821.GA1671@atmel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20150527032821.GA1671@atmel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00105.txt.bz2 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