From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18895 invoked by alias); 5 Mar 2004 01:34:06 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18887 invoked from network); 5 Mar 2004 01:34:05 -0000 Received: from unknown (HELO xinhuanet.com) (202.84.17.231) by sources.redhat.com with SMTP; 5 Mar 2004 01:34:05 -0000 Received: from sd-robert([61.177.18.179]) by xinhuanet.com(AIMC 2.9.5.6) with SMTP id jm04047dc48; Fri, 05 Mar 2004 09:37:25 +0800 Date: Fri, 05 Mar 2004 01:34:00 -0000 From: "Yorkwar" To: "vineets" Cc: "gdb" Subject: re: gdb breakpoint Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-AIMC-AUTH: yorkwar X-AIMC-MAILFROM: yorkwar@xinhuanet.com Message-ID: X-SW-Source: 2004-03/txt/msg00033.txt.bz2 Usually gdb together with the simulator is a single thread. GDB sees the integrated simulator as a set of functions. If you set a breakpoint in gdb, gdb will replace the appropriate instruction with some "break number"-like instruction and rember the original instruction. When the simulator meets with the gdb- inserted break instruction, it will return the control to gdb's main loop. Everytime gdb transfers it's control to simulator, it invokes sim_resume. That's my opinion:)