* Re: AW: libGDB architecture
[not found] <Pine.LNX.3.96.990831215030.4773A-100000@infcip52.uni-trier.de>
1999-08-31 13:29 ` AW: libGDB architecture Jason Molenda
@ 1999-08-31 14:19 ` Stan Shebs
1 sibling, 0 replies; 2+ messages in thread
From: Stan Shebs @ 1999-08-31 14:19 UTC (permalink / raw)
To: martin; +Cc: jtc, gdb
Date: Tue, 31 Aug 1999 21:52:51 +0200 (CEST)
From: Martin Baulig <martin@home-of-linux.org>
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 <msnyder@cygnus.com>
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 <ac131313@cygnus.com>
To: martin@home-of-linux.org
Cc: "'gdb@sourceware.cygnus.com'" <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: <B0000307205@ddaap077.deutschepost.de>
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 <msnyder@cygnus.com>
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 <stdio.h>
>
> 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 <ovidiu@cup.hp.com>
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 <ovidiu@cup.hp.com>
http://andromeda.cup.hp.com/ (inside HP's firewall only)
http://www.geocities.com/SiliconValley/Monitor/7464/
^ permalink raw reply [flat|nested] 2+ messages in thread