Re: [RFC] Making target layers into a real stack

John S. Kallal
2001-07-10T12:16:00Z

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2634 bytes --]

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.