From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22775 invoked by alias); 21 Jun 2002 21:46:09 -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 22756 invoked from network); 21 Jun 2002 21:46:05 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 21 Jun 2002 21:46:05 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3459D3D66; Fri, 21 Jun 2002 17:46:05 -0400 (EDT) Message-ID: <3D139E9D.70401@cygnus.com> Date: Fri, 21 Jun 2002 14:46:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Jim Blandy , gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage References: <20020619160004.38A625EA11@zwingli.cygnus.com> <3D1282DD.7000508@cygnus.com> <20020621014821.GA7608@nevyn.them.org> <3D135FE5.6090605@cygnus.com> <20020621173249.GA11443@nevyn.them.org> <20020621201716.GA23307@nevyn.them.org> <20020621210302.GA25010@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00177.txt.bz2 > This is the more substantial objection, it seems to me. But simply >> because libthread_db can't be used for cross-platform core files >> doesn't mean we shouldn't use it in the native case --- for the same >> reasons we use it on live processes. > > > Maybe.... I don't think the analogy holds. When we use it on live > processes there is always a system (somewhere) on which thread_db could > be running. That's why I was willing to use it in gdbserver. Of > course, it's ONE MORE library that needs to be on all my targets now, > which I'm not in love with. > > Debugging a core dump can't validly require access to a target. So > making "native debug of a core dump" different from the hopeful "cross > debug of a core dump" seems a bit dodgy. Yes. > I'd call the libthread_db > approach broken for this purpose (a little outside its design scope > perhaps). I think it reflects limitations of the current libthread-db interface rather than a broken approach. Andrew