From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9523 invoked by alias); 12 Nov 2013 17:02:14 -0000 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 Received: (qmail 9511 invoked by uid 89); 12 Nov 2013 17:02:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.2 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-bk0-f54.google.com Received: from Unknown (HELO mail-bk0-f54.google.com) (209.85.214.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 12 Nov 2013 17:02:13 +0000 Received: by mail-bk0-f54.google.com with SMTP id 6so2361347bkj.41 for ; Tue, 12 Nov 2013 09:02:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.204.171.12 with SMTP id f12mr10383375bkz.26.1384275723765; Tue, 12 Nov 2013 09:02:03 -0800 (PST) Received: by 10.204.245.195 with HTTP; Tue, 12 Nov 2013 09:02:03 -0800 (PST) Date: Tue, 12 Nov 2013 17:02:00 -0000 Message-ID: Subject: Feature Request From: Mark Manning To: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00045.txt.bz2 Not a huge fan of mailing lists, not sure I'm sending this to exactly the right place but anyway here goes... I am developing a Native Arm Forth compiler for an embedded Linux device. This compiler can be though of as a JIT compiler in that the opcodes it compiles are not written out to some separate object module but are literally inserted directly into the existing compilers process space. This is causing me no end of grief regarding the debugging of said JIT code because GDB flat refuses to simply disassemble and single step any opcodes not associated with some debug info. There will never be any debug information for the code being layed down by the compiler because once the compiler is working NO debugger will ever be needed, Forth simply does not require debuggers of this type. Right now a debugger is needed but if I cannot reliably lay down compiled code how can I expect to reliably lay down debug information and pass this to the debugger I'm using? This is a chicken/egg problem. So, I would like to request a feature that will allow GDB to simply single step opcodes anywhere within the process space owned by the application being debugged even if there is no debug symbols associated with it. I know GDB is open source but I stand a greater chance of being the first man to land on the sun than I would have of ever making any sense out of any of the GDB internals :) Ty in advance (not holding my breath) Mark Manning -- "When something can be read without effort, great effort has gone into its writing." -- Enrique Jardiel Poncela --