From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8701 invoked by alias); 2 Mar 2003 03:14:32 -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 8694 invoked from network); 2 Mar 2003 03:14:31 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.209.173) by 172.16.49.205 with SMTP; 2 Mar 2003 03:14:31 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id CC7A02A9C for ; Sat, 1 Mar 2003 22:16:39 -0500 (EST) Message-ID: <3E617797.5000704@redhat.com> Date: Sun, 02 Mar 2003 03:14:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: expected behavior of GNU/Linux gcore and corefiles Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00018.txt.bz2 (notes from a hallway conversation, I had a recollection that, at some stage, the attempt to load libthread db over a core file on GNU/Linux was disabled.) When using GDB on a live threaded program that puts all threads into tight infinite loops (while (1);), I'll do something like: $ ./a.out & Pid 1234 $ gdb ./a.out 1234 (gdb) info threads .... (gdb) quit As a user I'd also expect sequences such as: $ kill -QUIT 1234 $ gdb ./a.out core (gdb) info threads .... (gdb) quit and: $ gcore 1234 $ gdb ./a.out core (gdb) info threads .... (gdb) quit and: $ gdb ./a.out 1234 (gdb) gcore (gdb) quit $ gdb ./a.out core (gdb) info threads to all come back with effectively the same output. Further, on both live and corefile targets, I'd expect to be able to select/examine each thread vis: (gdb) thread 5 11 i = i + 1; (gdb) list 10 __thread__ i = 1; 11 i = i + 1; (gdb) print i $1 = 1 (which would involve thread local storage). Two problems come to mind: - Is the kernel including all the raw information needed to do this in the core file? - For GDB to completly implement the above, is it forced to use libthread-db? My instincts tell me that, to completly implement the above functionality, GDB is always going to need libthread-db. If GDB could implement the above on a core file without using libthread-db, then GDB could also implement the above on a live target also without using libthread-db. This is because a core file is always going to contain a subset of the information made available via ptrace et.al. Andrew