From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19934 invoked by alias); 24 Jan 2002 17:19:43 -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 19866 invoked from network); 24 Jan 2002 17:19:38 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 24 Jan 2002 17:19:38 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16TnXS-00079z-00; Thu, 24 Jan 2002 12:19:50 -0500 Date: Thu, 24 Jan 2002 09:19:00 -0000 From: Daniel Jacobowitz To: Johan Walles Cc: gdb@sources.redhat.com Subject: Re: Trouble debugging a Java Virtual Machine on Linux Message-ID: <20020124121950.A26301@nevyn.them.org> Mail-Followup-To: Johan Walles , gdb@sources.redhat.com References: <3C500AAC.5030709@appeal.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C500AAC.5030709@appeal.se> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-01/txt/msg00287.txt.bz2 On Thu, Jan 24, 2002 at 02:22:52PM +0100, Johan Walles wrote: > Hi! > > We are having trouble debugging our Java Virtual Machine on Linux. The > reason is that: > > JRockit (our virtual machine) uses ptrace() for controlling threads. > Gdb uses ptrace() for controlling processes / threads. Linux does not > allow two processes (like both gdb and JRockit) at a time to ptrace() > one target process (in our case, a Java thread). > > Thus, as both gdb and JRockit tries to PTRACE_ATTACH, they clash. When you try to explicitly attach to a thread, right? I doubt GDB would do so implicitly. > We have discussed a number of solutions to this problem, and we are > currently leaning towards making some sort of (non-JRockit specific) > modifications to gdb so that a debuggee can provide alternative ways for > gdb to manage processes. > > Now, I'd like very much to get some input from somebody knowledgable > about gdb. First, is there already some simple way of interfacing with > gdb to tell it to use our functions for managing processes and not its > own? If not, does patching gdb seem like a reasonable solution? What > would have to happen for these patches to get accepted into the official > gdb? You might want to look at User Mode Linux, which does something much the same. I believe it does it by wrapping GDB and faking the ptrace calls. Not quite ideal. My inclination is to tell you to use thread_db; but it doesn't actually provide everything that you need. It identifies threads but still requires that GDB attach to them itself. Defining a standard interface for the controlling of threads in this fashion would actually be tremendously useful - it could even be used to simplify, say, remote thread debugging. It could even make GDB a little more modular :) You would need to abstract the operations currently performed with ptrace, and provide hooks to accomplish them. Basically, lowlevel things like: - attach to thread - stop thread - you could get away without this, as it is generally done by signals and not ptrace, but you also need the related wait for thread and continue thread, and possibly stop all threads. - get/set thread registers/memory And highlevel things like: - New thread created - Thread destroyed etc. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer