This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] Making target layers into a real stack
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [RFC] Making target layers into a real stack
- From: John S. Kallal <jskallal at home dot com>
- Date: Tue, 10 Jul 2001 15:19:21 -0400
- Cc: gdb-patches at sources dot redhat dot com,Michael Snyder <msnyder at cygnus dot com>,Mark Kettenis <kettenis at science dot uva dot nl>
- References: <01062017044600.01102@CyberMax> <3B3C0E2E.7040508@cygnus.com>
On Friday 29 June 2001 01:12, Andrew Cagney wrote:
> > Andrew Cagney,
> >
> > In message http://sources.redhat.com/ml/gdb/2001-06/msg00015.html you
> > indicated interest in changes that start converting the target layers
> > into a real stack.
> >
> > How about the following patch that use a mix of macros and subroutines
> > in files target.h and target.c. How to use the macros in shown by
> > changing the files lin-lwp.c and thread-db.c to using the macros.
> >
> > If you think that this is the way to make the target layers into
> > something more stack-like you can apply the patch. If you think
> > that another way should be used, can you please give me some
> > pointer as to how to stack should be redesigned?
>
> I need to think about this and come up with a decent description as to
> how I think it should be done, sorry. The change I have in mind is more
> fundamental than this. Very briefly, each layer of the stack (if it is
> called that) would have its own local context (no global variables) and
> each layer would communicate with the layer above/below asynchronously.
> Each layer would be directly coupled to the event loop.
You are looking for a lot a work. If you can not give me more detailed
design information or example system to work from that would meet you
received your OK, any work by me is just a waste ofp˜€ïtime.
>
> This is a long way from what we have now :-/
>
> I suspect that the best thing to do is to address the immediate problems
> in lin-lwp.c and then, later the more fundamental change can follow.
My target layers patch was trying to address the immediate problems of
the lin-lwp.c! For me the major problem is lin-lwp.c functions making direct
calls to the child_target functions even when the child_target is not
currently installed in the target stack.
You can see the problems in the currently gdb snapshots by loading a
LinuxThreads program in gdb then set gdb to the remote target. Most user
command that follow will then be directed to the child_target functions even
while though the child_target is inactive.
> PS: In general macro's are bad and make the developers life hard. This
> is why gdbarch.[hc] was generated from gdbarch.sh.
Depends on your point of view. For programmers that are skilled with shell
programming, gdbarch.sh may make life better. I do very little UNIX shell
programming. For me gdbarch.sh just adds one more non-C source code file
to understand, modify, etc., of non-C code to the gdb source files.
Therefore, for me creating gdbarch[hc] from gdbarch.sh just makes working
with the gdb sources harder.