RE: [PATCH RFC] Make lin-lwp.c functions use target vectors, part 2

[John S. Kallal <jskallal at home dot com>]

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.