From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23254 invoked by alias); 6 Jan 2006 14:56:41 -0000 Received: (qmail 23247 invoked by uid 22791); 6 Jan 2006 14:56:40 -0000 X-Spam-Check-By: sourceware.org Received: from smtp01.mrf.mail.rcn.net (HELO smtp01.mrf.mail.rcn.net) (207.172.4.61) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jan 2006 14:56:39 +0000 Received: from 207-237-137-20.c3-0.80w-ubr16.nyr-80w.ny.cable.rcn.com (HELO [127.0.0.1]) ([207.237.137.20]) by smtp01.mrf.mail.rcn.net with ESMTP; 06 Jan 2006 09:56:33 -0500 X-IronPort-AV: i="3.99,339,1131339600"; d="scan'208"; a="150285454:sNHT346109716" Message-ID: <43BE8513.6020402@ajrh.net> Date: Fri, 06 Jan 2006 14:56:00 -0000 From: Anthony Heading User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Jim Blandy CC: Kris Warkentin , gdb@sources.redhat.com Subject: Re: debugging shared libraries References: <3518719F06577C4F85DA618E3C37AB9101CFC9FC@nimbus.ott.qnx.com> <43BDC9B8.3010906@ajrh.net> <8f2776cb0601060010l18ef2664laa60f4f9b3149ead@mail.gmail.com> In-Reply-To: <8f2776cb0601060010l18ef2664laa60f4f9b3149ead@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00039.txt.bz2 Jim Blandy wrote: > One of the problems here is that, technically, we don't know which > shared library the dynamic linker will actually load until the program > starts running, so we can't offer completion on its symbols. Hi Jim, But my original suggestion was about trying to sidestep that. If gdb is run on the shared library, it's clear even technically what library we're trying to debug! And indeed that already works fine (on ELF at least): % gdb y.so GNU gdb 6.4-debian [..] (gdb) break m mbstate_t my_buggy_shared_library_function() (gdb) break my_buggy_shared_library_function() Breakpoint 1 at 0x792: file y.cpp, line 5. The only problem that I can see is that within gdb you can't start a different executable. That is, most probably I have a main program, maybe just: main() { my_buggy_shared_library_function() } which I don't need to debug - I only need to use that executable to get the process started. (gdb) file y.so Reading symbols from /home/ajrh/y.so...done. Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) break y.cpp:5 Breakpoint 1 at 0x792: file y.cpp, line 5. (gdb) execute my_main_program Undefined command: "execute". Try "help". > We could try to guess what the dynamic linker was going to do, but > that's kind of a mess. Oh agreed, it's difficult if one tried to anticipate symbol definitions by chasing them from the main executable. That's why I'm suggesting something orthogonal: the programmer identifies the shared library to be debugged. But gdb currently seems a bit fixated on the idea that the debug target must be the executable object file, rather than one of the shared object files. Rgds Anthony