From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31845 invoked by alias); 15 Dec 2001 02:31:18 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 31814 invoked from network); 15 Dec 2001 02:31:16 -0000 Received: from unknown (HELO localhost.cygnus.com) (216.138.202.10) by sources.redhat.com with SMTP; 15 Dec 2001 02:31:16 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 877573E29; Fri, 14 Dec 2001 21:31:10 -0500 (EST) Message-ID: <3C1AB5EE.1000506@cygnus.com> Date: Fri, 14 Dec 2001 18:31:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.6) Gecko/20011207 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFA] Don't use thread_db on corefiles References: <20011213114847.A17989@nevyn.them.org> <3C190DDC.B32D6A7B@cygnus.com> <20011213152958.A30211@nevyn.them.org> <3C1931E3.E240B409@cygnus.com> <20011213180259.A11251@nevyn.them.org> <3C1933E7.E2B9DE87@cygnus.com> <20011213181006.A11536@nevyn.them.org> <3C193D13.AED0F79F@cygnus.com> <20011213185635.A12902@nevyn.them.org> <3C19543A.2580D12E@cygnus.com> <20011213232557.B20920@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00391.txt.bz2 > Oh, is that what you were talking about? Sorry, I must have been >> confused. >> >> So -- you are talking about building a single GDB that can debug >> 1) native x86 linux, and >> 2) MIPS multi-threaded linux corefiles. >> >> Is that right? > > > Well, that's not actually something I need to do, but I'd like it to be > possible. I only need for both native and cross-hosted debuggers to > both be able to get at the core files. But as things stand now, if we > fix thread_db to be able to do so using lin-lwp, then the native and > cross debuggers will get at the threads using completely different > interfaces. That worries me. At a technical level, it would mean making the thread:lwp mapping library multi-arch. I think Michael gave a good summary - that isn't a free lunch. (1) Returning to the problem at hand though, If you build --target=mips-unknown-linux-gnu does the resultant GDB include the native thread-db code? Surely it doesn't since, as you point out, it can't work. For the moment, would only be able to display threads, just the raw LWPs. Hmm, perhaps it is a native GDB looking at a threaded core file? In that case, yes the thread-db should drop its self on top. If that is causing an internal error then there is something messed up that should be fixed. Andrew (1) The unixware thread code is a prototype of this sort of thing. I say prototype since it really needs a proper target stack.