From: callum.gibson_at_db.com
Date: Fri May 24 2002 - 06:35:47 BST
dancebob_at_mindspring.com writes: }fully describe the setup below.) The solution is based on what }was suggested previously for following a forked child process. }Under Linux, each thread is given its own process, with a process }ID. Since my program is command-driven, I simply started it up so }that it would wait at the command prompt, and then attached the }debugger to the appropriate process. It's worth noting, for those who may not know, that the linux threads implementation is not POSIX compliant. According to POSIX, separate threads should not have separate PIDs, they are all part of the same process. Of course, in a userland thread implementation (such as *BSD) you have to get this. In Solaris, threads are userland objects which run on kernel objects called lwps, light weight processes (or what some people may refer to as kernel threads - strictly speaking this is incorrect as a kernel thread refers to a thread of execution in a multithreaded kernel). There are various tools in solaris available to see these lwps within an executable. I guess the upshot of all this is: a) "Proper" debugging of threads with debugger support is only possible where threads are supported by a kernel interface of some sort; in the pure userland case, multiple threads don't really exist at the same time so the debugger can't swap between them dynamically as you might with solaris' adb and dbx (and would like to with ups). b) You probably shouldn't rely on multiple pids as a methodology for debugging threads forever in case the linux people decide to fix their implementation. But while it works, go for it! c) Debugger support could be provided (on platforms where it makes sense) by use of something like solaris' libthread_db (I think linux has this too). If someone added support for libthread_db on those platforms that have it, it would be a bonus. It would also isolate linux folk from changes in the implementation (in theory). C Callum Gibson callum.gibson_at_db.com Global Markets IT, Deutsche Bank, Australia 61 2 9258 1620 ### The opinions in this message are mine and not Deutsche's ###
This archive was generated by hypermail 2.1.4 : Mon May 27 2002 - 11:55:21 BST