Version: CVS (using KDE KDE 3.1) Installed from: RedHat RPMs Can the debugger be fixed to not stop on shared library load event? I know the debugger internally needs to stop on these events to try and set deferred breakpoints, but does the user have get involved? This is pain for apps that use dlopen() to open lots of libraries. This dlopen stops my execution everytime it is hit. Could the debugger check to see if a user level breakpoint has been set on the interrupted line, if not then issue the go automatically? dpy->dlHandle = dlopen(dpy->clientDriverName, RTLD_NOW | RTLD_GLOBAL); #3 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 (gdb) next Stopped due to shared library event (gdb) backtrace #0 0x4000cf70 in _dl_debug_state_internal () from /lib/ld-linux.so.2 #1 0x4210f382 in dl_open_worker () from /lib/tls/libc.so.6 #2 0x4000c816 in _dl_catch_error_internal () from /lib/ld-linux.so.2 #3 0x4210ee19 in _dl_open () from /lib/tls/libc.so.6 #4 0x4012d00b in dlopen_doit () from /lib/libdl.so.2 #5 0x4000c816 in _dl_catch_error_internal () from /lib/ld-linux.so.2 #6 0x4012d416 in _dlerror_run () from /lib/libdl.so.2 #7 0x4012cfb4 in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2 #8 0x4004fefc in InitDriver (dpy=0x804a008) at miniglx.c:859 #9 0x400502f6 in XOpenDisplay (display_name=0x0) at miniglx.c:1020 #10 0x08048bee in main (argc=1, argv=0xbffffb84) at miniglxsample.c:116 #11 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
This problem occurs when doing the step over function and the dll load occurs inside the routine being stepped over. It does not happen when doing a continue.
See comments at the top of parts/debugger/gdbcontroller.cpp. You can turn this behaviour off in the debugger options, but doing so means that breakpoints in shared libs won't be loaded. As noted in the comments it could be improved by automatically turning this on when a brteakpoint is pending and off when no breakpoints are pending.
Limitation of gdb. A future version of gdb may support this better.