From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14476 invoked by alias); 29 Jan 2013 03:18:23 -0000 Received: (qmail 14464 invoked by uid 22791); 29 Jan 2013 03:18:21 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_LOW,TW_BJ,TW_JC X-Spam-Check-By: sourceware.org Received: from ms9.webland.ch (HELO ms9smtp.webland.ch) (92.43.217.109) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Jan 2013 03:18:15 +0000 Received: from ([84.74.172.50]) by ms9smtp.webland.ch (Webland Mail Server v. 10.4.1) with ASMTP id OEV16813; Tue, 29 Jan 2013 04:18:13 +0100 Received: from localhost (localhost [127.0.0.1]) by macserver.private (Postfix) with ESMTP id 2B0A81597A19; Tue, 29 Jan 2013 04:18:11 +0100 (CET) Received: from macserver.private ([127.0.0.1]) by localhost (macserver.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhA3p6SxKw93; Tue, 29 Jan 2013 04:18:10 +0100 (CET) Received: from [192.168.1.83] (unknown [192.168.1.83]) by macserver.private (Postfix) with ESMTP id E77B21597A0C; Tue, 29 Jan 2013 04:18:09 +0100 (CET) Message-ID: <51073F6D.3030806@indel.ch> Date: Tue, 29 Jan 2013 03:18:00 -0000 From: Raphael Zulliger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Aleksandar Ristovski CC: gdb@sourceware.org Subject: Re: Ensure correct symbol-file when attaching to a (remote) process References: <50D3FC31.1020103@indel.ch> <20121221161114.GA32638@host2.jankratochvil.net> <50D4D099.3030601@qnx.com> In-Reply-To: <50D4D099.3030601@qnx.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: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00079.txt.bz2 (I apologize: I've replied to this mail some weeks ago - but forgot to CC to the list. I therefore resend this email) On 12/21/2012 10:11 PM, Aleksandar Ristovski wrote: > Interesting timing. I have just posted > http://sourceware.org/ml/gdb-patches/2012-12/msg00776.html addressing > this issue. Indeed . Thanks! > > The check is not exhaustive, but for most practical purposes it should > suffice. It verifies that in-memory elf header and pheaders match > those found in the bfd. > > Of course it will not detect difference in all cases, e.g. very small > changes that do not affect loadable segment size. Example: > > - static int foo; > - static int bar; > + static int bar; > + static int foo; > > Still, it should be much better than no check at all. I'm not very familiar with ELF header information... But after to some quick investigation, it seems that this mechanism "only" helps to detect changes that affect "changes in size" or "changes of address", right? Moreover, if I understood it correctly, we'd have a fundamental problem using this mechanism in our scenario: We don't download the ELF file to the embedded system. Instead, we process the ELF file with objcopy (-Osrec) on the developer system and only download the produced SREC file - which contains no ELF header information anymore.