From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: martin@home-of-linux.org Cc: jtc@redback.com, gdb@sourceware.cygnus.com Subject: Re: AW: libGDB architecture Date: Tue, 31 Aug 1999 14:19:00 -0000 Message-id: <199908312119.OAA11349@andros.cygnus.com> References: X-SW-Source: 1999-q3/msg00267.html Date: Tue, 31 Aug 1999 21:52:51 +0200 (CEST) From: Martin Baulig It was my plan to have my work merged into the master GDB sources sometime in future and maintain it there. This is pretty exciting! One thing to keep in mind is that the FSF is a little more careful about ownership of copyright, and you'll need to assign your copyright to the FSF, at least for the changes to GDB. There is a good writeup of the procedures at http://egcs.cygnus.com/contribute.html Looking forward to seeing your contributions... Stan >From msnyder@cygnus.com Tue Aug 31 16:45:00 1999 From: Michael Snyder To: gdb@sourceware.cygnus.com Cc: sja@brightstareng.com Subject: Re: remote thread packet formats Date: Tue, 31 Aug 1999 16:45:00 -0000 Message-id: <37CC6714.7678@cygnus.com> References: <199908251754.KAA10340@prizm.glenvcr> X-SW-Source: 1999-q3/msg00268.html Content-length: 3924 Guys, please note that Cygnus never published or documented these thread messages. They were an early internal effort, and you can see how complicated and awkward they are. We hope to replace them with a better-designed and documented set. I do not recommend that you use these. Soon I will propose a new set of simpler query messages for thread info. Michael Snyder Ellery D'Souza [4611] wrote: > > Hi Stuart, > > > Can anyone shed more light on the remote thread packet formats ??? > > I want to add thread support for a custom RTOS. > > > > For example what does GDB expect in response to the "qL" and "qP" > > commands ??? > > I have deciphered the 'qL' command and have implemented it in > our 'inhouse' RTOS. > > I will try to explain the format of the 'qL' and 'qM' packets, but I might > get it wrong. (There is an example that follows the explanation). > > The 'qL' command is used to query for a thread list. > > Query packet format looks as follows: > > qL 'startflag':8 'threadcount':16 'nextthread':64 > > 'startflag' is either a '0' or '1'. A '1' means this > is the first query for a thread list. When 'startflag' > is '0', this is not the first query, so we must use the > 'nextthread' as the last thread we gave as reponse to the last > query packet. > > 'threadcount' is the maximum number of threads the response > packet can have. > > 'nextthread' is the argument to use in the 'argthread' for > the response thread, and is used if the 'startflag' is > set to '0'. > > Response packet: > > qM 'count':16 'done':8 'argthread':64 'threadsX':64 'threadsX':64 ... > > 'count' is the number of threads we are returning. > 'done'is either '0' or '1' - '1' means there are no more threads > to list, (another query packet is not needed). > 'argthread' is 'nextthread' from the query packet. > 'threadsX' is the threadid's of the threads from the remote target. > > Example: > > Thread ids : 0x50000001, 0x50000002, .... , 0x50000005 > Assume current thread is 0x50000001. > > Query packet will look as follows (I'm using threadcount = 3 to > make the packet look smaller - the actual number is quite big. > > Query #1: > qL1030000000050000001 > > startflag = 1 > threadcount = 3 > argthread = 0x50000001 > > Response #1: > qM0300000000050000001000000005000000100000000500000020000000050000003 > > count = 3 > done = 0 > argthread = 0x50000001 > thread1 = 0x50000001 > thread2 = 0x50000002 > thread3 = 0x50000003 > > Query #2: > qL0030000000050000003 > > startflag = 0 > threadcount = 3 > argthread = 0x50000003 > > Response #2: > qM021000000005000000300000000500000040000000050000005 > > count = 2 > done = 1 > argthread = 0x50000003 > thread1 = 0x50000004 > thread2 = 0x50000005 > > I think my example is better then my explanation. > Please feel free to point out and correct anything that is wrong. > > I did not attempt much with the 'qP' packet, the threads > on our 'inhouse' RTOS does not that much relevant information for > gdb. > > You might want to check out the following two function in remote.c > and the callers of said functions: > > remote_unpack_thread_info_response > pack_threadinfo_request > > -- > Ellery D'Souza > edsouza@glenayre.com >From ac131313@cygnus.com Tue Aug 31 16:53:00 1999 From: Andrew Cagney To: martin@home-of-linux.org Cc: "'gdb@sourceware.cygnus.com'" Subject: Re: AW: libGDB architecture Date: Tue, 31 Aug 1999 16:53:00 -0000 Message-id: <37CC6A87.2B80F92B@cygnus.com> References: X-SW-Source: 1999-q3/msg00269.html Content-length: 953 "Baulig, ITS P A800, TR" wrote: > > Oh fine. > > Since I'm already working on a guile interface to gdb, I'd be glad to help > you with the scheme-specific builder code. > Sorry, no, I've thrown you. I'm (er we're) _not_ working in a guile interface to GDB. Rather we're concentrating on the internal GDB changes needed to accomodate scripting languages (which clearly includes guile). From our end we just don't want to see it locked down to a specific language. Your feedback on how suitable the model is to guile and any/all contributed code would be most welcome. What I ment to say was that Cygnus have got some code working to where we are satisified that the basic model is correct. As they say, we're too embarrised to show you the details :-) We're now looking to take the idea's and have them reviewed publicaly. After review and consequent revision, the code can hopefully become part of the official GDB sources. enjoy, Andrew >From msnyder@cygnus.com Tue Aug 31 17:00:00 1999 From: Michael Snyder To: gdb@sourceware.cygnus.com Cc: ptr@paragraph.ru Subject: Re: gdb 4.18 on Solaris 7 x86? Date: Tue, 31 Aug 1999 17:00:00 -0000 Message-id: <37CC6A59.5106@cygnus.com> References: <14273.5137.480144.257285@icecle> X-SW-Source: 1999-q3/msg00270.html Content-length: 1844 Petr Ovchenkov wrote: > > Is anybody made 4.18 working under Solaris 7 x86? I don't have a Solaris 7 x86 system, but it works fine for me on Solaris 6 x86. I'm not sure what might have changed in Solaris 7. > I made changes in gdb/procfs.c so no more > "Inappropriate ioctl for device" happens, and correct permittions for > /proc/XXXX/crt. But still can't set any breakpoint (indeed can, > but gdb don't stop on it). Can't comment without seeing your changes. I've never seen that message, and breakpoints are working fine for me on Solaris 6 x86. > > more test.c > #include > > int main( int argc, char **argv ) > { > printf( "%s", "Hello, GNU!\n" ); > return 0; > } > > gcc -ggdb test.c -lthread Just curious -- why are you linking libthread to this program? > GNU gdb 4.18 > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-pc-solaris2.7"... > (gdb) break main > Breakpoint 1 at 0x80489b2: file test.c, line 5. > (gdb) run > Starting program: /export/home/ptr/tmp/Test/a.out > Hello, GNU! > /proc/11504/ctl: No such file or directory. > procfs_write_pcwstop failed > (gdb) quit > The program is running. Exit anyway? (y or n) y > > > > When gdb say "/proc/11504/ctl: No such file or directory.", process > already exited. When I try "target solaris-thread", result the same. > > Can any help? > > If somebody interesting by /proc/... workaround for Solaris 7, > patch for available. I'd be willing to look at your patch. Michael Snyder >From ovidiu@cup.hp.com Tue Aug 31 17:40:00 1999 From: Ovidiu Predescu To: gdb@sourceware.cygnus.com Subject: Re: libGDB architecture Date: Tue, 31 Aug 1999 17:40:00 -0000 Message-id: <199909010040.RAA11704@hpcll563.cup.hp.com> X-SW-Source: 1999-q3/msg00271.html Content-length: 3467 Hi, Sorry for being so late, but only now I had some time to read through the libGDB architecture proposal thread. Andrew, please correct me if I'm wrong here. My understanding of the proposal is that we'll have an abstract layer on top of GDB that receives commands through an input stream and spits out the GDB internal structures in a given format, that could easily be changed to meet one's particular needs. There are at least two obvious advantages for such an approach: (1) there is no need to change much of the GDB's internals in order to support it and (2) a libGDB client could be implemented in any language, since there's no coupling between the two layers. Here are some of my observations of what's going on so far. >From the the work that Jim Ingham, Tom Tromey, Keith Seitz, Martin Hunt and others did inside Cygnus on the gdbtk interface, from my previous experience with a Perl prototype and the current Python integration work we're doing here and from the work that Martin Baulig is doing on the Guile interface, it looks like we need a more tightly coupled interface with GDB. It seems that what we really need is the ability to have access to the internal GDB structures and functions directly and not through an additional layer, which adds a certain amount of burden in how you deal with GDB internals. It also looks like there is a lot of code duplication in all these glue layers. Things like getting the backtrace, finding the function name given a pc and lots more are copied from various places in GDB in all these clients. This is not a good thing since it doesn't promote code reuse. In addition, fixing a bug somewhere requires fixes in the other places that copied the code. This happens because GDB's code does not make a clear distinction between the parts that do actual computation and the ones that print out the results. I think we should try to separate the two parts and have computation functions and associated printing functions. Computation functions should just create structures or set-up global values that are used later on by the printing functions. These would just walk on existing structures and print out their content. With this approach it's a lot easier to glue on top of GDB clients like gdbtk, Guile, Python or whatever else, because all we have to do then is just export the functions that we need using SWIG and they automagically appear as native functions in the interpreted languages that SWIG supports (Tcl, Guile, Python, Perl and even Java). The next thing after this is to figure out a way to have all these languages share code and data between them. Imagine that there is a piece of code which you need in Guile, but you don't want to rewrite it in Python in order to be able to use it. Having the ability to call Guile code from Python and passing back and forth data in and from your favorite language would be very nice. The idea is to have people scripting GDB in Perl, Guile, Tcl or Python, all at once, from the same binary. This would be the true freedom of the user ;-)! But this is a completely different story... Does the approach of separating the functionality inside GDB sound reasonable? I know that there's a lot more work than what Andrew proposed but I think this will help us a lot in the long run. Regards, Ovidiu -- Ovidiu Predescu http://andromeda.cup.hp.com/ (inside HP's firewall only) http://www.geocities.com/SiliconValley/Monitor/7464/