Re: Eclipse CDT and gdb

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: Eclipse CDT and gdb



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
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 !


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 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.
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
> You may change your MinGW Account Options or unsubscribe at:

View this message in context:
Sent from the MinGW - User mailing list archive at

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at: