> We all know that gdbserver's thread support is in the toilet, but I'm > wondering what the gurus do when it comes to trying to debug threaded > programs remotely. buffff...
All my experience performing above is related with custom debugging via serial terminals, custom hardware resources and either udp or tcpip as main path to record traces and logs of special software resources as fifos or buffers weakly coupled to the application critical variables and data structures. To be really effective all this instrumentation must be as less intrusive as your software design/application can provide/allow.. > The best idea I had on the matter was to have each thread call a dummy > function, stupid_gdbserver_hack(), which I could break on as gdbserver > became aware of each thread, but that didn't work at all. :-) Maybe a new approach.. to be honest i lost the track about the threading support under mmuless machines long time ago... Anyhow, I agree with you that this stuff is really tricky, uhmm but What about if you can not break the program flow to see all the picture ? What about if you don't know where the breakpoint must be toggled ? Lot of times, you would see the thread exploding somewhere when a driver/app/another-thread did something weird maybe 5 minutes before.. Which tool will focus the bug before ? Very likely a combination of both debugging strategies.. > > So far I've been pretty lucky and not needed to worry about this too much, > but I'm curious as to what others can and have done in the past? Fundamental: Tons of patience and try to see as little as be possible the blood lost around. > -A. Best Regards _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
