From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-34218-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 21438 invoked by alias); 20 Apr 2009 08:01:21 -0000
Received: (qmail 20718 invoked by uid 22791); 20 Apr 2009 08:01:18 -0000
X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from qw-out-1920.google.com (HELO qw-out-1920.google.com) (74.125.92.150)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Apr 2009 08:01:13 +0000
Received: by qw-out-1920.google.com with SMTP id 4so574592qwk.24         for <gdb@sourceware.org>; Mon, 20 Apr 2009 01:01:09 -0700 (PDT)
Received: by 10.220.87.80 with SMTP id v16mr5398655vcl.19.1240214469630;         Mon, 20 Apr 2009 01:01:09 -0700 (PDT)
Received: from ?192.168.43.19? ([212.143.139.215])         by mx.google.com with ESMTPS id 4sm12419064yxj.7.2009.04.20.01.01.05         (version=TLSv1/SSLv3 cipher=RC4-MD5);         Mon, 20 Apr 2009 01:01:07 -0700 (PDT)
Message-ID: <49EC2AC1.6080903@gmail.com>
Date: Mon, 20 Apr 2009 14:47:00 -0000
From: Lennyk <lennyk430@gmail.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Michael Snyder <msnyder@vmware.com>
CC: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: Core dump information when code is optimized
References: <49E6D676.9000108@gmail.com> <49E76456.80907@vmware.com>
In-Reply-To: <49E76456.80907@vmware.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2009-04/txt/msg00152.txt.bz2

Thanks!

In the meantime I found how to separate the debug and symbol information 
from the binary executable - using objcopy:

1) Copy only the debug & symbol information from the binary to another file:
    objcopy --only-keep-debug <your_binary_filename> <output_file>
2) Strip the original binary file from its debug & symbol information:
    objcopy --strip-debug <your_binary_filename>
3) Link between the stripped binary and the debug & symbol information 
file created in step (1):
    objcopy --add-gnu-debuglink=<file_with_debug_info> <stripped_binary>

That's it! now the binary executable is optimized in size - and the core 
dump generates debug & symbol information from the created output file 
(in step (1)).

Enjoy,
Lenny.

Michael Snyder wrote:
> Lennyk wrote:
>> Hi,
>>
>> When I compile only with -O1 flag - my core dump information does not 
>> show line number or offset (when a segmentation fault has occurred).
>> Only when I add the -g flag does the core dump contain line number 
>> information - but the executable's size grows significantly!
>>
>> Is there a way to get this information with core dump - but maintain 
>> the optimized sized executable?
>
> It is -g that matters, not -O.
>
> -g generates line info.  This info goes into your executable, but it
> does not increase your memory footprint -- only the size of the file.
> In other words this line info is not copied into memory at runtime.
>
> Which means that it also does not appear in the corefile, so your
> corefile should not get significantly bigger.
>
>