From: nicolasR <nic...@st...> - 2008-11-19 12:05:47
|
Hi, I am using CDT 5.0.1 release and gdb 6.8, and need to debug a dll. My config is (in config->debugger->shared lib tabs): -Enable: Load shared libraries symbols automatically -Disable: Stop on shared library events I found also that gdb stops many times as written previously. Now after the 1st stops I just added the gdb cmd: "set stop-on-solib-events 0" Then after a run the breakpoints are never stopping the run. => So I think the " set stop-on-solib-events 1" is correctly setup. For me the solution is that CDT should recognize "solib-events" and if not requested to "Stop on shared library events", continue the execution. I can't use the 6.6 workaround. My application is debugging a PYD, python DLL. The launch application is the python.exe interpreter using a .py script files. So I can't stop the execution with a breakpoint. I think a asm{int $3} in my dll/pyd is a solution, but I would appreciate a better solution. Did you solved this issue ? Thanks for your help ! Cheers, Nicolas. Rafael Fernandes wrote: > > Doug Schaefer escreveu: >> Rafael Fernandes wrote: >> >>> Hi, >>> >>> Does anyone use Eclipse CDT? >>> When I debug an application with it, gdb stops many times at >>> ntdll!LdrAccessResource(). >>> It still works fine after I send "continue" to it, but it's annoying to >>> do that everytime I debug. >>> >>> The call stack is like this: >>> >>> 6 ntdll!LdrAccessResource() 0x7c90eb94 >>> 5 ntdll!ZwMapViewOfSection() 0x7c90dc61 >>> 4 snwprintf() 0x7c91c3da >>> 3 ntdll!RtlValidateUnicodeString() 0x7c916071 >>> 2 ntdll!LdrShutdownProcess() 0x7c9162da >>> 1 <symbol is not available> 0x00000000 >>> >>> I'm using gdb version 6.8 >>> >>> Did anyone else have this problem? Any ideas? >>> >>> Thanks. >>> >>> >>> >> >> Yes, this is something I've been trying to figure out too. I'm convinced >> at the moment that it's because of the way the CDT handles "pending" >> breakpoints, i.e. it tried to manage it itself. We set up >> stop-on-solib-events so that when DLLs get loaded, we try to set any of >> the breakpoints that failed during the main program load. I think gdb is >> choking on the solib event handling and you are showing a familiar stack >> trace that tells me you've run into the same thing. >> >> I'll be working on integrating the 6.8 gdb over the next few months and >> adding in proper support for gdb's pending breakpoints. In the meantime, >> things are kinda broken. >> >> Cheers, >> Doug Schaefer >> >> >> > > Thanks for the info Doug, I'll use gdb 6.6 instead, it doesn't have this > problem with CDT. > > Good luck with the integration, I hope it doesn't give you too much > trouble. :) > > Rafael > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > > -- View this message in context: http://www.nabble.com/Eclipse-CDT-and-gdb-tp16765391p20578479.html Sent from the MinGW - User mailing list archive at Nabble.com. |