From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 378 invoked by alias); 14 Feb 2008 18:58:46 -0000 Received: (qmail 370 invoked by uid 22791); 14 Feb 2008 18:58:45 -0000 X-Spam-Check-By: sourceware.org Received: from sca-es-mail-1.Sun.COM (HELO sca-es-mail-1.sun.com) (192.18.43.132) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 14 Feb 2008 18:58:22 +0000 Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1EIwKwd014152 for ; Thu, 14 Feb 2008 10:58:20 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW800501MI4NX00@fe-sfbay-10.sun.com> (original mail from Gordon.Prieur@Sun.COM) for gdb@sourceware.org; Thu, 14 Feb 2008 10:58:20 -0800 (PST) Received: from [129.146.82.55] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW800IHFSOWVG30@fe-sfbay-10.sun.com> for gdb@sourceware.org; Thu, 14 Feb 2008 10:58:08 -0800 (PST) Date: Thu, 14 Feb 2008 18:58:00 -0000 From: Gordon Prieur Subject: Re: stop-on-solib-events and Cygwin (or MinGW) In-reply-to: <20080214181353.GA7518@caradoc.them.org> To: gdb@sourceware.org Message-id: <47B48F3A.7070002@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_F4p6m1hyvmKZi7MaVCQGxw)" References: <47B473F8.5050401@sun.com> <20080214170852.GA3552@caradoc.them.org> <47B47D3B.8050708@sun.com> <20080214181353.GA7518@caradoc.them.org> User-Agent: Thunderbird 1.5 (X11/20060113) 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: 2008-02/txt/msg00103.txt.bz2 This is a multi-part message in MIME format. --Boundary_(ID_F4p6m1hyvmKZi7MaVCQGxw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-length: 2909 Daniel Jacobowitz wrote: > On Thu, Feb 14, 2008 at 09:41:15AM -0800, Gordon Prieur wrote: > >> Its customer driven. In NetBeans, breakpoints persist outside of a gdb >> session. >> The simplified scenario I'm using in my test cases contains 2 files, >> main.c and >> shared.c (shared.c builds into a dll). If I link main.c with the shared >> library then >> when I start debugging main, all breakpoints in shared.c are active. >> >> If I don't link the dll into main but explicitly dlopen it, the >> breakpoints aren't >> active unless I set them after the dlopen. >> > > That sounds like a bug in GDB. We need a test case. Actually, it > sounds like win32/2369. Anyway, there is no reason this should not > work from GDB without your having to do anything special. > Its similar to 2369 but there are several differences. First off, I'm running in mi mode and I don't really expect it to handle breakpoints in unloaded dlls. In command line, it asks if it should be left "pending on future shared library load". But I also tried it from the command line (w/o mi) and it still failed. But that scenario isn't identical to the one in 2369. In 2369, gdb tells you the bp fails to get set. In my case (using Cygwin gdb 6.5.50) I get a message "Pending breakpoint \"shared.c:5\" resolved" but it gets ignored. I reran with a breakpoint in my main program (before the call to the bp in my dll) and both worked. I've attached my sources. Since I built from NetBeans projects I'm not including any Makefiles. Build shared.c into a dll and reference it from app.c. Since I didn't want to muck with dlopen finding the dll, I hardcoded the path in app.c. You'll need to change it to point to the location you put libshared.dll. >> Will this be part of gbd 6.8? >> > > Yes. > > >> From my point of view, its only fixed when >> I can >> recommend a specific version of Cygwin and/or MinGW to my customers. Even >> then, I'll need to support legacy versions without this feature. So even >> if its >> fixed, I think I'll need to maintain my alternate Windows implementation for >> a while. >> > > If you don't want to ship your own GDB, or require a new release, > then we can't help you with GDB bugs - if you find a time machine > sitting around somewhere, do let me know :-) > We're considering bundling compilers, gdb, and make with NetBeans. In the mean time, I have a time machine called patience:-) Incidentally, my alternate Windows implementation seems to work. I set a bp in dlopen, call "finish", and reset all failed NetBeans breakpoints . Note that "NetBeans breakpoints" are different than gdb breakpoints. When I start gdb I attempt to create a gdb breakpoint for each NetBeans breakpoint. The failed ones are the ones I'll retry after the dlopen. In most cases, the failure is because the bp is in code not compiled into the app. Gordon --Boundary_(ID_F4p6m1hyvmKZi7MaVCQGxw) Content-type: text/x-csrc; name=app.c Content-transfer-encoding: 7BIT Content-disposition: inline; filename=app.c Content-length: 574 #include #include int main(int argc, char **argv) { void *handle; int (*square)(int); const char *error; handle = dlopen ("C:/Documents and Settings/gordonp/My Documents/NetBeansProjects/DlopenTest_1/shared/dist/Debug/Cygwin-Windows/libshared.dll", RTLD_LAZY); if (!handle) { fputs (dlerror(), stderr); exit(1); } square = dlsym(handle, "square"); if ((error = dlerror()) != NULL) { fputs(error, stderr); exit(1); } printf ("%d\n", (*square)(1)); printf ("%d\n", (*square)(2)); printf ("%d\n", (*square)(3)); dlclose(handle); } --Boundary_(ID_F4p6m1hyvmKZi7MaVCQGxw) Content-type: text/x-csrc; name=shared.c Content-transfer-encoding: 7BIT Content-disposition: inline; filename=shared.c Content-length: 66 #include int square(int arg) { return (arg*arg); } --Boundary_(ID_F4p6m1hyvmKZi7MaVCQGxw)--