This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
RE: [PATCH RFC] Make lin-lwp.c functions use target vectors, part 2
- To: gdb-patches at sources dot redhat dot com,kettenis at science dot uva dot nl
- Subject: RE: [PATCH RFC] Make lin-lwp.c functions use target vectors, part 2
- From: John S. Kallal <jskallal at home dot com>
- Date: Tue, 22 May 2001 23:38:58 -0400
- Cc: Michael Snyder <msnyder at cygnus dot com>
- Reply-To: 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.