From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30534 invoked by alias); 30 Apr 2011 03:02:41 -0000 Received: (qmail 30521 invoked by uid 22791); 30 Apr 2011 03:02:40 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from seraph.oankali.net (HELO seraph.oankali.net) (209.9.237.222) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 30 Apr 2011 03:02:24 +0000 Received: from [192.168.1.2] (darwin.oankali.net [98.113.78.28]) (authenticated bits=0) by seraph.oankali.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3U32KIx021706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Apr 2011 23:02:21 -0400 Date: Sat, 30 Apr 2011 03:02:00 -0000 From: Richard Silverman To: Paul Koning cc: GDB Mailing List Subject: Re: teaching gdb about new types? In-Reply-To: <0CC3B1C2-DD9F-4A4A-AA07-9E2FC72D6C9D@dell.com> Message-ID: References: <0CC3B1C2-DD9F-4A4A-AA07-9E2FC72D6C9D@dell.com> User-Agent: Alpine 2.01 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-IsSubscribed: yes 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 X-SW-Source: 2011-04/txt/msg00171.txt.bz2 On Fri, 29 Apr 2011, Paul Koning wrote: > If you're worried about types rather than line numbers, I would think that all you'd need is a symbol table that has the right type definitions in it. If you know what they are supposed to be, you can supply such a symbol table easily enough. > > paul I tried that -- I created a little file: ---------------------------------------- #include pthread_cond_t p; pthread_mutex_t m; ---------------------------------------- ... and built an object from it. However, I can't find a way to get gdb to use it while debugging an existing program, that is, to add the type definitions in that object to its existing set. The commands "symbol-file" and "add-symbol-file" seem likely candidates, but they don't appear to do it. - Richard > On Apr 29, 2011, at 4:42 PM, Richard Silverman wrote: > >> On Fri, 29 Apr 2011, Paul Koning wrote: >> >>> The simple answer is to get a copy of libc.so with debug symbols, and load that symbol table. You don't have to replace the library itself to do that. >>> >>> paul >> >> I know, thanks; but the host is Solaris, and Oracle doesn't appear to provide this (although I'm pursuing it with them.). I could also build the OpenSolaris libc and hope they're close enough. However, it really seems as if one ought to be able to do what I described. >> >> - Richard >> >>> On Apr 29, 2011, at 2:36 PM, Richard Silverman wrote: >>> >>>> Hello, >>>> >>>> This seems as if it should be simple, but I can't find an answer. I would like to teach gdb about new types relevant to the program being debugged, which are not among the debugging info in the program. A concrete example: I have a program which uses pthreads from libc. It calls: >>>> >>>> int pthread_cond_wait(pthread_cond_t *restrict cond, >>>> pthread_mutex_t *restrict mutex); >>>> >>>> ... and the argument types are defined in system header files. But libc.so has no debugging info, so gdb doesn't know about these types, and can't interpret the arguments for me. How can I teach gdb about these types? >>>> >>>> Thanks, >>>> >>>> - Richard >>> >>> >>> > > > -- Richard Silverman res@qoxp.net