From mboxrd@z Thu Jan 1 00:00:00 1970 From: John S. Kallal To: gdb-patches@sources.redhat.com, kettenis@science.uva.nl Cc: Michael Snyder Subject: RE: [PATCH RFC] Make lin-lwp.c functions use target vectors, part 2 Date: Tue, 22 May 2001 20:39:00 -0000 Message-id: <01052223412201.01552@CyberMax> X-SW-Source: 2001-05/msg00426.html Hi Mark, This is the 2nd part of my reply. >As you've noticed, the code in lin-lwp.c does some very low-level >things. In fact it is so closely tied to the "child_ops" layer, that >I don't feel comfortable applying your patch, even though in the long >run a patch similar to yours may be the way to go. I think it is I think that my patch does not much reduce the tie between routines in lin-lwp.c and the native routine of the process_stratum when gdb is operating with the native linux process_stratum target. When gdb is operating with the remote target and a threaded program gdb still remain a mess an unworkable mess. My patch just made some of the lin-lwp.c routines indirectly call the "child_ops" layer through the target vector. I tried not make any changes to what action gdb takes when operating in linux native mode with programs using LinuxThreads. This patch is only intended to help in removing the tie between the lin-lwp.c and "child_ops" by some later patch. I hope to build on my initial patches to provide a demostraction version of gdbserver thread debugging. Additional changes to the GDB remote protocol from the demostation version of the GDB remote protocol would mostly be in gdb's remote.c and gdbserver's sever.c files. See my notes below. FYI, I ran the gdb testsuite after the patch with no change in the testsuite results. >essential to envision how gdb and gdbserver should interact when >debugging multi-threaded code first, before starting to do any >coding. I'm not terribly well familiar with the GDB remote protocol, >but I do think that changes to the remote protocol and/or gdbserver >are necessary (probably both). Unfortunately I won't have time in the >near future to work on this myself. Volunteers to work on this stuff >are welcome! Currently under linux threading a thread=LWP=process. A linux multithreaded program is just a set of user processes that share a single address space. The code in thread-db.c and lin-lwp.c seems to controls programs that use the LinuxThreads library by the following three means: a) Placing breakpoints into selected locations within the LinuxThread library code. b) Using ptrace for attaching to newly cloned processes c) Misc. signal handling and manipulation. The gdb remote protocol currently provides for thread selection. However, the current remote protocol assumes that the remote server can handle all the thread control without any help from gdb. The current gdb remote protocol has no support for LWP infomation or LWP control. Also the current remote protocol may not have the needed support for the signal handling and manipulation. One way would be to add the current linux thread handling found in the gdb files thread-db.c, to the linux gdbserver. This looks to be a great deal of programming work. This would expand the memory size of gdbserver manyfold. This increased memory size may not be reasonable for all embedded linux systems. I also think that adding hardware watchpoint to linux's version of gdbserver would be very helpful. Software watchpoint can be very slow. Software watchpoint over a remote link even slow. Add hardware watchpoints would also add to gdbserver's memory size. Another way would be to add to gdb's target vector and the gdb remote protocol the additional features needed for controlling a program using the LinuxThread's library. If additional gdb target vectors for the above b) and c) low level operations are added. Then adding the low level operations to gdbserver should not be hard. What additional low level operations the gdb remote protocol must support would be clearer after gdb's target vectors are extended. I am not sure, but Micheal Snyder libremote seems to be using the first way to add remote LinuxThread's debugging. If Michael Snyder indicated that a beta libremote would be released by early July, I would stop my current work and see what libremote provides and what it requires when release.