From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7690 invoked by alias); 8 Jan 2007 15:11:37 -0000 Received: (qmail 7680 invoked by uid 22791); 8 Jan 2007 15:11:36 -0000 X-Spam-Check-By: sourceware.org Received: from sophia.inria.fr (HELO sophia.inria.fr) (138.96.64.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 08 Jan 2007 15:11:26 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.8/8.13.4) with ESMTP id l08FBNmK013172 for ; Mon, 8 Jan 2007 16:11:23 +0100 Received: from garfield.inria.fr (garfield.inria.fr [138.96.88.66]) (authenticated bits=0) by sophia.inria.fr (8.13.8/8.13.4) with ESMTP id l08F9wlA012179 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 8 Jan 2007 16:09:58 +0100 Subject: gdb and dynamic loader namespaces From: Mathieu Lacage To: gdb@sourceware.org Content-Type: multipart/mixed; boundary="=-3LiTdiWvtDigdyXAGPVv" Date: Mon, 08 Jan 2007 15:11:00 -0000 Message-Id: <1168268998.21818.44.camel@garfield.inria.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Mon, 08 Jan 2007 16:09:58 +0100 (MET) 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: 2007-01/txt/msg00115.txt.bz2 --=-3LiTdiWvtDigdyXAGPVv Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1048 hi, While playing a bit with the dlmopen (this is the stock glibc coming with a FC5 system) function, it occured to me that gdb 6.6 does not seem to be able to deal with code loaded in a process through this function. The attached test program shows that, indeed an extra binary is loaded in my process address space but gdb seems unable to place a breakpoint in any of the functions defined in this binary (something like "b gtk_window_new"). So, I tried to figure out how I could fix this in gdb: a bit of debugging shows that gdb is notified of dlmopen calls through the r_debug structure since "set stop-on-solib-events 1" triggers correctly an event upon dlmopen. The question then is why gdb does not add the new binary to its map. Maybe someone more knowledgeable than me about the layout of the gdb code source could point me to the piece of code which updates and manipulates the gdb map of binaries used during symbol lookup ? (I am using an x86 linux system) I apologize before hand if this email is off-topic, regards, Mathieu -- --=-3LiTdiWvtDigdyXAGPVv Content-Disposition: attachment; filename=test.c Content-Type: text/x-csrc; name=test.c; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-length: 1209 #define _GNU_SOURCE #include #include #include static void print_map (struct link_map *map) { struct link_map *tmp; for (tmp = map; tmp != 0; tmp = tmp->l_next) { printf (" 0x%lx: \"%s\"\n", tmp->l_addr, tmp->l_name?tmp->l_name:"null"); } } int main (int argc, char *argv[]) { void * handle; struct link_map *map; dlerror (); handle = dlopen (NULL, RTLD_LAZY); if (handle == NULL) { printf ("error getting handle for main binary: %s\n", dlerror ()); goto error; } if (dlinfo (handle, RTLD_DI_LINKMAP, &map) == -1) { printf ("error getting link map: %s\n", dlerror ()); goto error; } printf ("map before dlmopen\n"); print_map (map); void *module = dlmopen (LM_ID_NEWLM, "/usr/lib/libgtk-x11-2.0.so", RTLD_NOW); if (module == 0) { printf ("error=\"%s\"", dlerror ()); return; } printf ("default map after dlmopen\n"); print_map (map); if (dlinfo (module, RTLD_DI_LINKMAP, &map) == -1) { printf ("error getting 2nd link map: %s\n", dlerror ()); goto error; } printf ("2nd map after dlmopen\n"); print_map (map); return 0; error: return -1; } --=-3LiTdiWvtDigdyXAGPVv--