From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25961 invoked by alias); 21 Jan 2010 18:29:56 -0000 Received: (qmail 25953 invoked by uid 22791); 21 Jan 2010 18:29:55 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 21 Jan 2010 18:29:49 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 9FA5C13120; Thu, 21 Jan 2010 10:29:48 -0800 (PST) Received: from [10.20.125.16] (unknown [10.20.125.16]) by mailhost2.vmware.com (Postfix) with ESMTP id 957948E9B1; Thu, 21 Jan 2010 10:29:48 -0800 (PST) Message-ID: <4B589CF2.2040304@vmware.com> Date: Thu, 21 Jan 2010 18:29:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20090624) MIME-Version: 1.0 To: Dave Korn CC: Jie Zhang , "gdb@sourceware.org" Subject: Re: Reset breakpoint after load? References: <4B5560E0.3080901@analog.com> <4B582A02.2040501@gmail.com> In-Reply-To: <4B582A02.2040501@gmail.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: 2010-01/txt/msg00173.txt.bz2 Dave Korn wrote: > On 19/01/2010 07:36, Jie Zhang wrote: > >> gdb-comm.exp sets breakpoints on exit and abort before load. The problem >> is that GDB tries to skip prologue according to what it reads from >> memory, which might contain random data since the executable has not >> been loaded into memory. In my case, sometimes skip_prologue might skip >> one or two more instructions, which happens to be an exception >> instruction and will trap the processor into an exception event loop >> after running the executable before hit the breakpoints. > > Something is wrong here. Before the inferior is started, gdb should be > looking at the prologue bytes from the executable image file, not the inferior > memory. Is something going wrong in gdb_comm_file_cmd()? Dave, Jie, I don't believe that gdb can tell when the (remote) inferior is started. All gdb knows is that target remote is started. Thus, if we connect to target remote and then load the image, there is an interval during which gdb will attempt to read the prologue bytes from un-initialized target memory. Seems to me, that interval is a bad time to set breakpoints. Michael