From mboxrd@z Thu Jan 1 00:00:00 1970 From: John S. Kallal To: Andrew Cagney Cc: gdb-patches@sources.redhat.com, Michael Snyder , Mark Kettenis Subject: Re: [RFC] Making target layers into a real stack Date: Tue, 10 Jul 2001 12:16:00 -0000 Message-id: <01071015192100.00894@CyberMax> References: <01062017044600.01102@CyberMax> <3B3C0E2E.7040508@cygnus.com> X-SW-Source: 2001-07/msg00231.html 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.