From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16689 invoked by alias); 5 Dec 2009 21:12:27 -0000 Received: (qmail 16679 invoked by uid 22791); 5 Dec 2009 21:12:26 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from oden.vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Dec 2009 21:12:19 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 65E5726EE3F; Sat, 5 Dec 2009 22:12:15 +0100 (CET) Received: from polhem (c83-253-20-250.bredband.comhem.se [83.253.20.250]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id 441DE26EE17; Sat, 5 Dec 2009 22:12:15 +0100 (CET) From: "Jakob Engblom" To: "'Dave Korn'" , References: <4B197BC0.5010708@gmail.com> In-Reply-To: <4B197BC0.5010708@gmail.com> Subject: RE: Software-vs-hardware single-step vs. sim/non-sim targets. Date: Sat, 05 Dec 2009 21:12:00 -0000 Message-ID: <013801ca75ef$9ff77a30$dfe66e90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-cr-hashedpuzzle: BFUK CtuE EGqM FJ83 GegW HE3a HMo/ ImTg KOLP K4SZ SCmP VQzb XB/c XDxV ZBW0 ZQ48;2;ZABhAHYAZQAuAGsAbwByAG4ALgBjAHkAZwB3AGkAbgBAAGcAbwBvAGcAbABlAG0AYQBpAGwALgBjAG8AbQA7AGcAZABiAEAAcwBvAHUAcgBjAGUAdwBhAHIAZQAuAG8AcgBnAA==;Sosha1_v1;7;{0E5828FB-9998-47F8-AF89-1DAB3DDB60D9};agBhAGsAbwBiAEAAdgBpAHIAdAB1AHQAZQBjAGgALgBjAG8AbQA=;Sat, 05 Dec 2009 21:12:11 GMT;UgBFADoAIABTAG8AZgB0AHcAYQByAGUALQB2AHMALQBoAGEAcgBkAHcAYQByAGUAIABzAGkAbgBnAGwAZQAtAHMAdABlAHAAIAB2AHMALgAgAHMAaQBtAC8AbgBvAG4ALQBzAGkAbQAgAHQAYQByAGcAZQB0AHMALgA= x-cr-puzzleid: {0E5828FB-9998-47F8-AF89-1DAB3DDB60D9} 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: 2009-12/txt/msg00039.txt.bz2 > I have a GDB port for a custom target, a sim-based simulator, and a gdbstub > for use on the real thing. GDB can single step the simulator of course, since > the support for simulated hardware-single-step is built in, but I'd like to > save bytes in the gdbstub by not implementing support for the "s" command. Can't you just use gdb-serial as the level of intermediation? And hide all implementations behind a common facade, and use a single standard gdb as the front-end? /jakob