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.