From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9981 invoked by alias); 21 Dec 2012 18:17:32 -0000 Received: (qmail 9971 invoked by uid 22791); 21 Dec 2012 18:17:30 -0000 X-SWARE-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_BRBL_LASTEXT,RCVD_IN_HOSTKARMA_YE,RCVD_IN_MSPIKE_BL,RCVD_IN_MSPIKE_L3,RCVD_IN_NJABL_RELAY,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from new.toad.com (HELO new.toad.com) (209.237.225.253) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Dec 2012 18:17:23 +0000 Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id qBLJH6Il028006; Fri, 21 Dec 2012 11:17:06 -0800 Message-Id: <201212211917.qBLJH6Il028006@new.toad.com> To: Jan Kratochvil cc: Raphael Zulliger , gdb@sourceware.org Subject: Re: Ensure correct symbol-file when attaching to a (remote) process In-reply-to: <20121221161114.GA32638@host2.jankratochvil.net> References: <50D3FC31.1020103@indel.ch> <20121221161114.GA32638@host2.jankratochvil.net> Comments: In-reply-to Jan Kratochvil message dated "Fri, 21 Dec 2012 17:11:14 +0100." Date: Fri, 21 Dec 2012 18:17:00 -0000 From: John Gilmore 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: 2012-12/txt/msg00072.txt.bz2 > > Is there really no such mechanism in GDB? > > There is no such reliable mechanism in general. If gdb had a local copy of the binary object file (not just the symbols), it could try to read arbitrary locations in that file, and read the same locations in the remote target, and compare the two. (This would take a bit of work, since it would have to manually walk the target stack to find and access the local object file.) Only if you read back every byte of the object file could you be SURE that the remote target contained the same thing. In that case you might as well have just written the entire object file TO the target. Either would be extremely slow. Testing just a few places in memory is unlikely to detect the kinds of small changes that debugging cycles frequently make to programs. This is why gdb doesn't do it by default (I considered it when making the target stack first work). If someone wrote such a command as a GDB enhancement, and submitted the patch, it could probably be added as a specific command ("verify-target percent" where percent is what fraction of the address space to compare -- default should probably be super quick, 0.00001% or something). You'd also have to make a decision about what to do with data areas and bss (zeroed) areas. In a remote target, after the program has been run one or more times, these will normally be overwritten with updated variable values. When restarting the program, there is no guarantee that the program's initialization code will restore them, nor that the rest of the program's code won't depend on the initial values in these variables. When merely connecting GDB to debug an already-running target in mid-execution, these variables can have any values. The best you can do in an automated way is to check the areas of memory that are intended to contain instructions and read-only data. (And in some targets, such as the Linux kernel, even that check will fail, since it links initialization code separately from running code, and overwrites the initialization code with data areas after it has initialized the kernel.) John