* Re: -Wmissing-prototypes ... [not found] <Pine.SUN.3.91.991202192443.17848B-100000@is> @ 1999-12-02 22:19 ` Andreas Jaeger 0 siblings, 0 replies; 4+ messages in thread From: Andreas Jaeger @ 1999-12-02 22:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb, Andrew Cagney, DJ Delorie >>>>> Eli Zaretskii writes: Eli> On 2 Dec 1999, Andreas Jaeger wrote: Eli> +static void print_387_status (unsigned, struct env387 *); >> Shouldn't this be unsigned int? AFAIK the new ISO C99 standard >> mandates it - and it doesn't harm here. Eli> I didn't know we are supposed to be compatible with C9x. It's probably a Eli> good idea to tell this explicitly, so all platform maintainers know. That was a personal comment - I'm not a gdb maintainer. Eli> Yes, you can change all places with "unsigned" into "unsigned int". Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From toddpw@windriver.com Thu Dec 02 23:19:00 1999 From: Todd Whitesel <toddpw@windriver.com> To: davidwilliams@ozemail.com.au Cc: gdb@sourceware.cygnus.com (GDB Developers) Subject: Re: exceptionHandler for 68K Date: Thu, 02 Dec 1999 23:19:00 -0000 Message-id: <199912030719.XAA19824@alabama.wrs.com> References: <01BF3D76.F8F982C0.davidwilliams@ozemail.com.au> X-SW-Source: 1999-q4/msg00431.html Content-length: 997 > to the exception handler. My problem is that I dont understand where this > table of jsr's is located... Admittedly I have not looked at the code, but it may be generated by a macro, so it might be easy to miss. You could try building a debug stub and objdump it to see where all the vector table entries point to. According to the discussion you posted, it sounds like there's a label called 'exception' and the 256 JSR's are stored underneath that. So maybe you should search the source for references to that label? > The m68k-stub has code to determine the exception number by taking the > return address on the stack (the return address is the location in the jsr > table) and adding 1530 and then dividing by 6. Feh. Use BSR.W and divide by 4. Or chop up the table into four pieces, each a row of BSR.S instructions jumping to slightly different computation code at the bottom -- that lets you divide by 2 and save another 500 bytes or so. -- Todd Whitesel toddpw @ windriver.com From ac131313@cygnus.com Thu Dec 02 23:22:00 1999 From: Andrew Cagney <ac131313@cygnus.com> To: "davidwilliams@ozemail.com.au" <davidwilliams@ozemail.com.au> Cc: "'gdb mail list'" <gdb@sourceware.cygnus.com> Subject: Re: gdb stack in stub Date: Thu, 02 Dec 1999 23:22:00 -0000 Message-id: <38476F7E.B6A46989@cygnus.com> References: <01BF3D52.CD93EEA0.davidwilliams@ozemail.com.au> X-SW-Source: 1999-q4/msg00432.html Content-length: 881 David Williams wrote: > > Hi all, > > I noticed that a 10K local stack is allocated in the m68k-stub.c for it own > use when communcating with gdb. This seems excessive. I would like to leave > the stub code in my final application so that I can debug in the field (via > a special option). However it would be better if the stub consumed the > least amount of system resources as possible. > > Is there any problem with using my applications stack (if enough room is > allocated for GDB usage in addition to normal usage)? My application always > runs in supervisor mode. FYI, GDB likes to perform inferior function calls on the target stack. Watch the effect of: (gdb) print printf ("Hello world\n") If you try to use the target program's stack, GDB is very likely to trash it :-( enjoy, Andrew > What is likely max stack usage of GDB? > > TIA > David Williams. From ac131313@cygnus.com Fri Dec 03 00:52:00 1999 From: Andrew Cagney <ac131313@cygnus.com> To: Steven Johnson <sbjohnson@ozemail.com.au> Cc: jtc@redback.com, gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Fri, 03 Dec 1999 00:52:00 -0000 Message-id: <38478423.6ACE7BF8@cygnus.com> References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> X-SW-Source: 1999-q4/msg00433.html Content-length: 9163 Steven Johnson wrote: > It is based on my First Read of the current online version of protocol > specification at: > http://sourceware.cygnus.com/gdb/onlinedocs/gdb_14.html > Packet Structure: > > Simple structure, obviously originally designed to be able to be driven > manually from a TTY. (Hence it's ASCII nature.) However, the protocol > has evolved quite significantly and I doubt it could still be used very > efficiently from a TTY. That said, it still demarks frames effectively. One really useful thing to know is the command: (gdb) set remotedebug 1 (If there isn't already) there should be a reference to that command (or is successor). > Sequence Numbers: > > Definition of Sequence ID's needs work. Are they necessary? Are they > deprecated? What purpose do they currently serve within GDB? One would > imagine that they are used to allow GDB to handle retransmits from a > remote system. Reading between the lines, this is done to allow error > recovery when a transmission from target to host fails. Possible > sequence being: I guess the best description is ``in limbo''. Sequence ID's have been in the protocl for as long as anyone can remember but, at the same time no one can actually remeber them being used. True? I didn't deprecate it as there does need to be something for handling things like duplicate packets (so that finally the protocol can be used reliably across UDP and the like). Someone needs to sit down and fully specify this (or better) identify an existing protocol that can be used to specify the sequence-id's behavour. There should at least be a note pointing out the current status of sequence-ID's. > The 2 primary timing constraints I see that are missing are: > > Inter character times during a message transmission, and Ack/Nak > response times. > > If a message is only half received, the receiver has no ability without > a timeout mechanism of generating a NAK signalling failed receipt. If > this occurs, and there is no timeout on ACK/NAK reception, the entire > comms stream could Hang. Transmitter is Hung waiting for an ACK/NAK and > the Receiver is Hung waiting for the rest of the message. > > I would propose that something needs to be defined along the lines of: > > Once the $ character for the start of a packet is transmitted, each > subsequent byte must be received within "n" byte transmission times. > (This would allow for varying comms line speeds). Or alternately a > global timeout on the whole message could be define one "$" (start > sentinel) is sent, the complete message must be received within "X" > time. I personally favour the inter character time as opposed to > complete message time as it will work with any size message, however the > complete message time restrict the maximum size of any one message (to > how many bytes can be sent at the maximum rate for the period). These > tiemouts do not need to be very tight, as they are merely for complete > failure recovery and a little delay there does not hurt much. How GDB behaves should be clarified. However, any definition should avoid refering to absolute times and instead refer the user back to a number of knobs that can be tweeked from the GDB command line. This in turn suggests that there should be a section describing the protocol's behavour with direct references to things like the configurable timers. I've sometimes wondered about doing a proper SDL spec.... :-) > Identified Protocol Hole: > > Lets look at the following abstract scenario (Text in brackets are > supporting comments): > > <- $packet-data#checksum (Run Target Command) > -> + (Response is lost due to a line > error) > (Target runs for a very short period of time and then breaks). > -> $sequence-id:packet-data#checksum (Break Response - GDB takes as a > NAK, expecting a +, got a $). > <- $packet-data#checksum (GDB retransmits it's Run Target Command, > target restarts) > -> + (Response received OK by GDB). > (Target again starts running.) That is correct. The protocol, as it currently stands, is only robust against overrun errors (detected by a checksum failure). In pratice this has proven to be sufficient for almost all situtations. Because of the request/response nature of the protocol the probably of a dropped/corrupt ACK packet is very low. (I'm not saying this a good thing, just a lucky thing :-) This would suggest that at least the spec should make the known limitations clear. This is another reason why I've not simply abandoned the sequence-ID - I'm hopeing someone will do something about this :-) > Run Length Encoding: > > Is run length encoding supported in all packets, or just some packets? > (For example, not binary packets) > Why not allow lengths greater than 126? Or does this mean lengths > greater than 97 (as in 126-29) > If binary packets with 8 bit data can be sent, why not allow RLE to use > length also greater than 97. If the length maximum is really 126, then > this yields the character 0x9B which is 8 bits, wouldn't the maximum > length in this case be 226. Or is this a misprint? FYI, Any packet can be RLE. RLE handling is done as part of unpacking a packet. The code doesn't know if it is binary/ascii at that point. The old RLE size reflects the fact that a 7 bit printable character was used (the actual equation is RLE - ' ' +3). While binary packets could extend this, I don't think that there is any benefit. I've rarely seen an RLE stub in pratice. The benefits would be significant. GDB doesn't send RLE packets and, I think, it should. > Why are there 2 methods of RLE? Is it important for a Remote Target to > understand and process both, or is the "cisco encoding" a proprietary > extension of the GDB Remote protocol, and not part of the standard > implementation. The documentation of "cisco encoding" is confusing and > seems to conflict with standard RLE encoding. They appear to be mutually > exclusive. If they are both part of the protocol, how are they > distinguished when used? It's an unsupported extension. Idea's from CISCO are slowly being rolled back into the normal protocol. > Deprecated Messages: > > Should an implementation of the protocol implement the deprecated > messages or not? What is the significance of the deprecated messages to > the current implementation? (Your not the first one to ask that one :-) They are there as a very strong deterant for people thinking of re-using the relevant letters. This should probably be clarified. > Character Escaping: > > The mechanism of Escaping the characters is not defined. Further it is > only defined as used by write mem binary. Wouldn't it be useful for > future expansion of the protocol to define Character Escaping as a > global feature of the protocol, so that if any control characters were > required to be sent, they could be escaped in a consistent manner across > all messages. Also, wouldn't the full list of escape characters be > $,#,+,-,*,0x7d. Otherwise, + & - might be processed inadvertently as ACK > or NAK. If this can't happen, then why must they be avoided in RLE? If > they are escaped across all messages, then that means they could be used > in RLE and not treated specially. Beyond the X packet there is no escape mechanism. GDB assumes the connection is capable of transfering printable ascii. Escaping characters should probably be left to a lower layer. (A side note: The existing protocol spec mixes the packet specification and transfer in with the specification of the actual packet body - not a good way of defining a spec.) > 8/7 Bit protocol. > > With the documentation of RAW Binary transfers, the protocol moves from > being a strictly 7 bit affair into being a 8 bit capable protocol. If > this is so, then shouldn't all the restrictions that are placed from the > 7 bit protocol days be lifted to take advantage of the capabilities of > an 8 bit message stream. (RLE limitations, for example). Would anyone > seriously be using a computer that had a 7 bit limitation anymore > anyway? (At least a computer that would run GDB with remote debugging). I suspect that it will still be there for a while longer. Even if there were no broken serial controllers there will still be broken stubs :-( > Thoughts on consistency and future growth: > > Apply RLE as a feature of All messages. (Including binary messages, as > these can probably benefit significantly from it). > > Apply the Binary Escaping mechanism as a feature of the packet that is > performed on all messages prior to transmission and immediately after > reception. Define an exhaustive set of "Characters to be escaped". > > Introduce message timing constraints. > > Properly define sequence-id and allow it to be used from GDB to make > communications secure and reliable. FYI, the one I really wish someone would persue is a mechanism that allowed GDB to send console input down to the target. Cisco added code that does something however it isn't robust. To do this, I suspect that some of the other issues you've raised would also need to be addressed. thanks, Andrew From ac131313@cygnus.com Fri Dec 03 01:14:00 1999 From: Andrew Cagney <ac131313@cygnus.com> To: Jim Blandy <jimb@cygnus.com> Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.cygnus.com Subject: Re: ST(i) and MMj Date: Fri, 03 Dec 1999 01:14:00 -0000 Message-id: <38478987.EECEEBF@cygnus.com> References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> X-SW-Source: 1999-q4/msg00434.html Content-length: 1151 Jim Blandy wrote: > > > During that discussion I did agree that these registers should not be > > treated as separate, but it seems we meant different things. > > What I meant was that it is a Bad Idea to maintain separate data for > > each one of these sets. > > Ah. I see what you meant now. Yes, we misunderstood each other. > > > But I don't see why cannot GDB _think_ about %st(X) and %mmY as being > > separate registers while in reality they share the same data, if this > > sharing is concealed behind REGISTER_BYTE and REGISTER_RAW_SIZE (and > > possibly other functions/macros used to manipulate registers). What > > are the specific problems with this scheme? > > Grep the sources for NUM_REGS, and look for loops that traverse the > register set. Prove to yourself that none of these loops will break > if register X aliases register Y. Persuade yourself that nobody in > the future, innocent of the x86's sins, will write such a loop. > > I tried, but I couldn't manage it. :) I agree with Jim. The way GDB currently resolves register names/numbers ``freaks me out''. (Now about that REGISTER_VIRTUAL_NAME macro :-) Andrew From alexs@cygnus.co.uk Fri Dec 03 03:41:00 1999 From: "Alex Schuilenburg" <alexs@cygnus.co.uk> To: "Stan Shebs" <shebs@cygnus.com> Cc: <gdb@sourceware.cygnus.com>, "Hugo Tyson" <hmt@cygnus.co.uk> Subject: RE: Multi-threaded debugging within GDB & eCOS Date: Fri, 03 Dec 1999 03:41:00 -0000 Message-id: <NCBBKJPHEKGAJNNFGNBLCEMJDHAA.alexs@cygnus.co.uk> References: <199912030305.TAA24626@andros.cygnus.com> X-SW-Source: 1999-q4/msg00435.html Content-length: 4176 > GDB will "lock up". More precisely, GDB will sit quietly waiting for > the target to do something, not realizing that the user has caused a > deadlock by manually suspending thread A. This is as expected, since > GDB has no way to know that the program is in this state. In > practice, the user gets impatient, hits ^C, sees the current state, > and goes "oh yeah, my fault" and fixes. I figured it would. > GDB's default behavior is to give all threads a chance to run when > resuming, which generally prevents this kind of situation. We > introduced the scheduler-locking flag for those cases where the user > really really needs to lock out other threads, even if it might mean > the thread being stepped will block. Hugo and I had a discussion a while ago about the usefulness of this flag and come to the conclusion that it was not, or rather the semantics of it should be changed. Locking the scheduler is dangerous for this very reason. You may have interrupts occuring which need to be serviced on the target hardware and this method will lock out the service thread, and in certain cases even crash the hardware. So you really need to have a less intrusive method of debugging, particularly for deeply embedded real-time debugging. The solution we came up with for eCos was something similar to what I had done before. See below. > (I'd be interested to know if you have workarounds for this > fundamental problem though.) Sort of. I wrote a debugger for Helios which was targetted at multi-threaded non-intrusive debugging. For this I termed the phrase "loosly coupled debugging". Essentially the target hardware (e.g. threads not being debugged) had to keep on running, even when a bp was hit by a thread being debugged, else the h/w would die. I had a debug agent running on the h/w which would talk back to the debugger and let it know when a bp was hit, when an exception occurred etc, but more importantly it would run in conjunction with the application which was being debugged. That is, the debugger on the host could query the agent on the target at any time to query the status of the h/w and the status of actively running threads. You could do a backtrace which was a "sample" where a thread on the remote app was at when the bt command was executed, and set breakpoints within the app while the app was still running. More importantly I introduced the freezing and thawing of threads. This required some support from the RTOS. If you froze a thread, the RTOS would no longer schedule it for execution. Similarly threads were thawed to allow them to resume. So the user would freeze only the threads which they did not want to interact with the thread they were debugging. Naturally you could inspect the stack etc of a frozen thread as the full register context of the frozen thread was preserved and available to the agent, and hence the debugger. There was no concept of ^C as you always had a command line. If you wanted to stop the target entirely you would simply freeze all threads. Naturally the debug agent would be exempt. The cool thing was that you could leave the debug agent in your final app. So you could walk up to the running h/w in the field, hook a portable to the serial port, and attach the debugger. Hence you could query the target to find out what it was doing, what state threads were in, and if you had the matching source and symbol tables available, even start debugging it. Like attaching gdb to an active process on UNIX (which is where I snarfed the idea from). Things were a bit more complex (aren't they always) since you could debug the agent itself and still had to provide the ability to debug the RTOS which was controlling everything, including the agent. So threads could only be frozen if they were not consuming a system resource. That is, something which the debug agent or RTOS would need to fulfill its obligations. Of cource you could over-ride this to debug the kernel and system calls, but in these instances the agent could fall back into a gdb-stub mode, and the user suffered the consequences of freezing the hardware. At least they were warned... Cheers -- Alex ^ permalink raw reply [flat|nested] 4+ messages in thread
* -Wmissing-prototypes ...
@ 1999-11-27 18:50 Andrew Cagney
1999-09-20 0:46 ` -Wmissing-prototypes Andrew Cagney
[not found] ` <37CB6DBE.2083662F@cygnus.com>
0 siblings, 2 replies; 4+ messages in thread
From: Andrew Cagney @ 1999-11-27 18:50 UTC (permalink / raw)
To: gdb
FYI,
There is now a reasonable chance that GDB can be compiled with the
-Wmissing-prototypes option. Thanks to JimI, JimB and Fernando and
Elena for various specific cleanups.
Andrew
My current list is:
--enable-build-warnings=-Werror\
,-Wimplicit\
,-Wreturn-type\
,-Wcomment\
,-Wtrigraphs\
,-Wformat\
,-Wparentheses\
,-Wpointer-arith\
,-Wmissing-prototypes\
,-Woverloaded-virtual\
From cgf@cygnus.com Sat Nov 27 18:50:00 1999
From: cgf@cygnus.com (Chris Faylor)
To: gdb@sourceware.cygnus.com
Subject: Re: Debugging Windows Namespace extension dll
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <7rpjdk$a2b$1@cronkite.cygnus.com>
References: <l03130300b404ff236a3b@[138.251.135.28]>
X-SW-Source: 1999-q4/msg00333.html
Content-length: 1219
In article <l03130300b404ff236a3b@[138.251.135.28]>,
Mark Hindley <mh15@st-andrews.ac.uk> wrote:
>I am in the middle of writing a windows namespace extension implemented as
>an in process server dll. I have got the basic structure complete and it
>builds fine with gcc, but I can not get it to debug with gdb.
>
>I am trying:
>
>exec-file /windows/explorer.exe
>
>source-file MyDll.dll
>
>set args /root, {My CLSID},
>
>
>There appears to be 2 problems. I get an access violation when the dll is
>read, eith as the initial symbol file, or when it is loaded by explorer
>when the programme is run. The other is that I am unable to set any
>breakpoints. If I type
>
>break DllMain
>
>the reply is
>
>Cannot access memory at 0x....
The way that I normally do something like this is:
gdb /windows/explorer.exe
symbol-file MyDll.dll
set args /root
l DllMain
bp <first line number in DllMain>
run
As you probably, know using 'symbol-file' wipes out any existing symbol file
so this may not be exactly what you want. You could use add-sym if you know
the load address of your DLL.
Hope this helps,
Chris Faylor
--
cgf@cygnus.com
http://www.cygnus.com/
From ac131313@cygnus.com Sat Nov 27 18:50:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: -Werror -Wformat -Wimplicit
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <37CB6DBE.2083662F@cygnus.com>
X-SW-Source: 1999-q4/msg00334.html
Content-length: 1339
Just FYI,
The next snap (Jason only just made one) is very likely to be buildable
with the configuration option:
--enable-build-warnings=-Werror\
,-Wimplicit\
,-Wreturn-type\
,-Wcomment\
,-Wtrigraphs\
,-Wformat\
,-Wparentheses\
,-Wpointer-arith\
,-Woverloaded-virtual
I've cleaned up numerous targets and, for them, the source code contains
*ZERO* warnings of the types listed above.
Assuming that your host's header files are in good condition, it
shouldn't take much for a few maintainers to wack their native build
into similar shape.
For the curious. The full list looks like:
enable_build_warnings=`echo -Werror\
\
,$W\
,-Wimplicit\
,-Wreturn-type\
,$Wunused\
,$Wswitch\
,-Wcomment\
,-Wtrigraphs\
,-Wformat\
,$Wchar$subscripts\
,$Wuninitialized\
,-Wparentheses\
,$Wtemplate$debugging\
\
,$Wtraditional\
,$Wshadow\
,$Wid$clash$len\
,-Wpointer-arith\
,$Wcast$qual\
,$Wcast$align\
,$Wwrite$strings\
,$Wconversion\
,$Waggregate$return\
,$Wstrict$prototypes\
,$Wmissing$prototypes\
,$Wmissing$declarations\
,$Wredundant$decls\
,$Wnested$externs\
,$Wenum$clash\
,-Woverloaded-virtual\
,$Winline\
so while there is a long way to go, the list of those working is very
useful (namely -Wformat, -Wimplicit, -Wparen and -Wcomment - especially
-Wformat!).
enjoy,
Andrew
From msnyder@cygnus.com Sat Nov 27 18:50: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: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <37CC6A59.5106@cygnus.com>
References: <14273.5137.480144.257285@icecle>
X-SW-Source: 1999-q4/msg00339.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 jingham@leda.cygnus.com Sat Nov 27 18:50:00 1999
From: James Ingham <jingham@leda.cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Next release of GDB
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <mf4sh6el89.fsf@leda.cygnus.com>
References: <199909051618.SAA01412@caracol.first.gmd.de>
X-SW-Source: 1999-q4/msg00341.html
Content-length: 1942
Clemens Klein-Robbenhaar <robbe@prosun.first.gmd.de> writes:
Presumably, the Objective C support would be in the MacOS X Support
bits. MacOS X being based on NextStep, which is in turn heavily
Objective C based...
Jim
> Stan Shebs wrote:
>
> [...]
> > Here are some additional things that I would like to see, but that
> > ought not to hold up the release if they can't be gotten in:
> >
> > * first version of libgdb, w/Guile scripting
> > * GNU/Linux thread_db library support
> > * asynchronous execution for GNU/Linux
> > * fork following for GNU/Linux
> > * HP WDB 1.1 bits
>>>>>>>>>>>> > * Apple MacOS X support bits
> > * Current VxWorks (Tornado) support bits
> > * Current LynxOS support bits
> > * m68k BDM patches
> > * Ada language support
> >
> > There are probably many other important things that I'm forgetting,
> > please speak up and remind me about them!
> [...]
>
> .. what about Objective C support? That should not be to hard.
> (For gdb-4.16 and gdb-4.17, there was a patch,
> afaik by Michael Snyder <msnyder@NeXT.com>;
> still present at ftp://alpha.gnu.org/gnu/gnustep/contrib
> This patch does not work for gdb-4.18, but only because the code
> changed too much for the "patch" program to apply, I think.)
>
> Have I missed some point here -- has the Objective C patch
> been rejected because of pricipal reasons not supporting Objective C
> in gdb? As I scanned the archives, I found only
> Christopher Seawood <cls@seawood.org>
> http://sourceware.cygnus.com/ml/gdb-patches/1998/msg00115.html
> raising the same issue, but without getting any feedback.
>
> Or has just nobody been around so far interested in doing the
> (little) work?
>
>
> regards,
> clemens
--
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham jingham@cygnus.com
Cygnus Solutions Inc.
From msnyder@cygnus.com Sat Nov 27 18:50:00 1999
From: Michael Snyder <msnyder@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: overlays and hardware breakpoints
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <37D5CAFE.7F3B@cygnus.com>
References: <5mwvu8ft9t.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00343.html
Content-length: 386
J.T. Conklin wrote:
> But while studying breakpoint.c, I noticed that there does not seem
> to be support for using hardware breakpoints and overlays. Although
> CPUs with hardware breakpoint registers typically have large address
> spaces, it is not inconceivable that overlays may be used.
Almost surely an oversight. If you care to add it,
I'll review it.
Michael
From ac131313@cygnus.com Sat Nov 27 18:50:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: ERF TARGET_WAITKIND_EOF
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <37F0529C.B0694A78@cygnus.com>
X-SW-Source: 1999-q4/msg00337.html
Content-length: 1119
Hello,
(I've also seen LOST, DEAD, DOA, KABOOM, KAPUT ..suggested :-).
At present when communication with a target is lost, the target
internally indicates the falure by directly killing the target
(mourn_inferior()) and longjmping out of there (error ()).
When it comes to async and providing clean library like behavour, having
things randomly call error() isn't nice (besides longjmp's are bad N'kay
;-).
I'd like to propose the new ``enum target_waitkind'' TARGET_WAITKIND_EOF
that target_wait() can return to indicate that the target just went
kaput. The semantics would require the target_*() vector to post the the
failure reason on gdb_stderr and then return TARGET_WAINTKIND_EOF.
Initially the remote async and remote extended-async targets would be
the only ones capable of returning this result. This would ensure that
other non-async targets would not be affected.
Clearly this is going to stur up WFI (or what ever it is today).
I'd like comments on this and (perhaphs) someone willing to handle the
WFI side. I'd be willing to take care of the remote.c side.
Andrew
From msnyder@cygnus.com Sat Nov 27 18:50:00 1999
From: "Michael Snyder" <msnyder@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Lets talk to each other...
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <7svnb4$5cb$1@cronkite.cygnus.com>
References: <19990927151348.A22339@sco.com> <990928043014.ZM29997@ocotillo.lan> <199909280657.IAA00175@delius.kettenis.nl> <990929033103.ZM17365@ocotillo.lan> <199909291554.RAA18158@landau.wins.uva.nl>
X-SW-Source: 1999-q4/msg00345.html
Content-length: 307
Mark Kettenis wrote in message <199909291554.RAA18158@landau.wins.uva.nl>...
>HJ's patch has
>the drawback that it also tries to solve a totally unrelated problem
>(curses on Solaris 7), which needs some more investigation and
>probably should be
And is being.
>fixed in autoconf instead.
^ permalink raw reply [flat|nested] 4+ messages in thread* -Wmissing-prototypes ... 1999-11-27 18:50 -Wmissing-prototypes Andrew Cagney @ 1999-09-20 0:46 ` Andrew Cagney [not found] ` <37CB6DBE.2083662F@cygnus.com> 1 sibling, 0 replies; 4+ messages in thread From: Andrew Cagney @ 1999-09-20 0:46 UTC (permalink / raw) To: gdb FYI, There is now a reasonable chance that GDB can be compiled with the -Wmissing-prototypes option. Thanks to JimI, JimB and Fernando and Elena for various specific cleanups. Andrew My current list is: --enable-build-warnings=-Werror\ ,-Wimplicit\ ,-Wreturn-type\ ,-Wcomment\ ,-Wtrigraphs\ ,-Wformat\ ,-Wparentheses\ ,-Wpointer-arith\ ,-Wmissing-prototypes\ ,-Woverloaded-virtual\ From ac131313@cygnus.com Mon Sep 20 19:47:00 1999 From: Andrew Cagney <ac131313@cygnus.com> To: Ovidiu Predescu <ovidiu@cup.hp.com> Cc: Jim Blandy <jimb@cygnus.com>, Stan Shebs <shebs@cygnus.com>, gdb@sourceware.cygnus.com Subject: Re: libGDB architecture Date: Mon, 20 Sep 1999 19:47:00 -0000 Message-id: <37E6F077.F75C8BE8@cygnus.com> References: <199909162200.PAA21351@hercules.cup.hp.com> X-SW-Source: 1999-q3/msg00370.html Content-length: 3693 Ovidiu Predescu wrote: > > On 16 Sep 1999 14:08:39 -0500, Jim Blandy <jimb@cygnus.com> wrote: > > > How should we handle objects allocated on obstacks? Most of the > > symbolic info (types; variables) is allocated this way. I don't think > > it's practical to keep the entire obstack around until all its > > objects' reference counts have dropped to zero. > > I think we should expect clients to behave nicely and not keep references to > such objects around for an indefinite time. Once they get a message that such > an object became invalid, the client should release its reference. Another > approach for the client would be to copy such information in its own internal > data structures, if they are needed for a longer time, but this shouldn't be > the case. To re-iterate my position, as a first pass, I strongly prefer to keep a certain distance between GDB's internals and the client. When it comes to performance, I can't see the access mechanisms provided for primitives such as breakpoints and frames even appearing on the radar. In fact, to the best of my knowledge the current biggest hot spot (everyone keeps pointing a finger at) is the overhead/hazards of serializing GDB's communication (via a pty say). I think a better (safer, more likely to succeed) approach would be to, in parallel with the introduction of a robust interface, start investigating what have been identified as other (likely) hot spots. Interestingly, many of the below are actually independent of the libGDB interface: o variable update when stepping I believe that the GDBtk team (who do access GDB's internals using a more direct mechanism) have already identified this as a performance hot spot. o A per thread cache. Well actually the lack of it :-) Here is another example of why it is better to have the client keep a safe distance from GDB. The last thing we want is for clients to be locked into the existing mechanisms. o memory transfer / large target data structures In this case I think more fundamental internal GDB changes will be needed before you can start thinking about providing direct access to GDB's internal memory structures. Perhaps HP are interested in taking on the task of re-working GDB's local memory cache so that a more direct interface is possible. I kind of suspect that papers on distributed shared memory would be highly relevant. While that work is in progress a slow robust mechanism would continue to be used. o (as always) symbol table / name lookup A hot topic in anyone's language :-) > Releasing the obstacks happens usually as a result of an action triggered by > the client, so it should be prepared to release these objects. We can document > which are those functions in the API that deallocate entire obstacks; these > shouldn't be that many, the only important places I can think of are associated > with freeing of an object file and reloading of symbols. (Stack frames are implemented using obstacks.) I don't think it is reasonable to assume that the client is in control :-). As GDB becomes more and more asynchronous it is just as likely that the target will trigger events as it is the client. Consider GDB debugging a multi-threaded target. The long term plan is for GDB to allow some threads to run free while others are halted - in such a situation any assumption that the client is in control has to be thrown out the window :-). > Either way we need the client's cooperation, which is what you require anyway > from somebody that lives with you in the same data space ;-). Your too trusting :-) Andrew PS: See Tcl_IncrRefCount and Tcl_DecrRefCount From ac131313@cygnus.com Mon Sep 20 22:45:00 1999 From: Andrew Cagney <ac131313@cygnus.com> To: Stan Shebs <shebs@cygnus.com> Cc: cagney@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: QUIT as a function? Date: Mon, 20 Sep 1999 22:45:00 -0000 Message-id: <37E71AEB.B9C35E7D@cygnus.com> References: <199909171842.LAA10740@andros.cygnus.com> X-SW-Source: 1999-q3/msg00371.html Content-length: 736 Stan Shebs wrote: > > From: Andrew Cagney <ac131313@cygnus.com> > Date: Fri, 17 Sep 1999 15:14:42 +1000 > > Is there any reason for not converting QUIT into a function? > > Yes, QUIT appears in the inner loops of the symbol readers, which > are known to be compute-bound and some of the most time-critical > code in all GDB. So I'd want to see some comparative performance > numbers, especially on hosts with lame calling conventions, before > we go messing with QUIT. True. I guess a pre-cursor would be to ``fix'' the symbol table stuff so that it wasn't so dependent on linear search algorithms :-(. The performance gains made there should more than out way any performance loss with an extra function call. Andrew From jingham@leda.cygnus.com Tue Sep 21 11:31:00 1999 From: James Ingham <jingham@leda.cygnus.com> To: gdb@sourceware.cygnus.com Subject: Re: libGDB architecture Date: Tue, 21 Sep 1999 11:31:00 -0000 Message-id: <mfn1ugceho.fsf@leda.cygnus.com> References: <199909162200.PAA21351@hercules.cup.hp.com> <37E6F077.F75C8BE8@cygnus.com> X-SW-Source: 1999-q3/msg00372.html Content-length: 2073 Andrew Cagney <ac131313@cygnus.com> writes: > > I think a better (safer, more likely to succeed) approach would be to, > in parallel with the introduction of a robust interface, start > investigating what have been identified as other (likely) hot spots. > Interestingly, many of the below are actually independent of the libGDB > interface: > I agree with Andrew here. We can get a lot of benefit just breaking down some of the atomic operations in the GDB interface into useable bits. We have already done this with the variable interface (see gdbtk-variable.c) Another example where you need to do this is in the backtrace command. For most GUI purposes, you really don't want an undifferentiated list of 100 stack elements with all their arguments, names, types... Parsing and displaying this was very slow. You really want one command that just gives you the list of functions on the stack. Then a way to get the args (preferrably already list-ified) for each level. That way you can do intelligent things like only fetch what fits in the current window, and get the others on scrolling or whatever... This is just one other example. There are other places where providing a more discrete interface into gdb would be a big benefit, and probably reduce most of the need to get your hands on the actual data in gdb. I am still worried about parsing very large arrays, etc, however. For this to be fast, you probably will have to somehow get the data directly... > Your too trusting :-) > > Andrew > > PS: See Tcl_IncrRefCount and Tcl_DecrRefCount There are actually two places where Tcl does preservation of data. One is in the Object system, which uses the calls Andrew sites above, and one is for clients that want to hold data over a call that may potentially free it - see Tcl_Preserve and Tcl_EventuallyFree. Jim -- ++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++ Jim Ingham jingham@cygnus.com Cygnus Solutions Inc. From masahiro@lsi.nec.co.jp Wed Sep 22 02:35:00 1999 From: Masahiro Fukuda <masahiro@lsi.nec.co.jp> To: gdb@sourceware.cygnus.com Cc: masahiro@lsi.nec.co.jp Subject: one proposal ... `Z'T`,'ADDR`,'LENGTH`,'IGNORE_COUNT ?? Date: Wed, 22 Sep 1999 02:35:00 -0000 Message-id: <199909220933.SAA06550@mctcs13.ucom.lsi.nec.co.jp> X-SW-Source: 1999-q3/msg00373.html Content-length: 7368 Hi, I recently realize that gdb-19990830 extends some keyword into gdb serial protocol, and I also read some mailing list archives. My name is Masahiro Fukuda. Independently, I added some keyword (actually [B/b] just like J.T.C did) into gdb serial protocol in order to transmit "breakpoint" to gdbserver instead of writing TRAP instruction. Some arguements including <addr>, <length>, <ignore_count> follow breakpiont keyword in my code. Those command packets are generated in v850_insert_hw_breakpint()/v850_insert_watchpoint() in v850-tdep.c. Andrew suggested me that I would join gdb mailing list when I wrote an e-mail to him how I should do for this kind of proposal. Expected typical scenario is shown below when ignore count is transmitted to target. Suppose, there are three breakponits/watchpoints and each has following ignore count. number type ignore count ------------------------------------------ #1 hardware breakpoint 7 #2 read watchpoint 5 #3 write watchpoint 3 Please find the gdb/target communication below with illustration. (a) Breakpoints/watchpoints are inserted before continue. (b) Gdb continues target. Target decrements each ignore count every time when target hits respective breakpoint/watchpoint without making any communication with gdb as far as respective ignore count does not equal to zero. At last, target tells gdb after it hits breakpoint/watchpoint whose ignore count equal to zero. (c) breakpoints/watchpoints are removed after target stopps and each current ignore count is retrieved from target. ---------------------- illustration ---------------------- gdb side -------------------- target side (a)insert breakpoints -----------------------> (#1, 7) before continue -----------------------> (#2, 5) with ignore count -----------------------> (#3, 3) (b)continue -----------------------------------> wait for target | #1 hit (#1, 7->6) to stop | #1 hit (#1, 6->5) | #1 hit (#1, 5->4) | #2 hit (#2, 5->4) time | #3 hit (#3, 3->2) | #1 hit (#1, 4->3) | #1 hit (#1, 3->2) | #1 hit (#1, 2->1) | #2 hit (#2, 4->3) | #3 hit (#3, 2->1) | #1 hit (#1, 1->0) V #1 hit (#1, 0->!) target stop <------------------------------- (c)remove breakponits -----------------------> (#1 ) remained ignore count returns (0) <--------- remove breakponits -----------------------> (#2 ) remained ignore count returns (3) <--------- remove breakponits -----------------------> (#3 ) remained ignore count returns (1) <--------- ---------------------- illustration ---------------------- Next, please find the proposed Z/z packet. ---------------------- proposed Z/z packet ---------------------- remove `z'T`,'ADDR`,'LENGTH` `z' should retrieve break remained IGNORE_COUNT or from target. watcchpoint reply `OK'IGNORE_COUNT for success The others are the same as current spec. insert `Z'T`,'ADDR`,'LENGTH`,'IGNORE_COUNT just add IGNORE_COUNT break The othera are the same or as current spec. watcchpoint ---------------------- proposed Z/Z packet ---------------------- ---------------------- current Z/Z packet ---------------------- remove break or `z'T`,'ADDR`,'LENGTH See `Z'. watchpoint *(draft)* *(optional)* insert break or `Z'T`,'ADDR`,'LENGTH T is type: `0' - software watchpoint *(draft)* breakpoint, `1' - hardware *(optional)* breakpoint, `2' - write watchpoint, `3' - read watchpoint, `4' - access watchpoint; ADDR is address; LENGTH is in bytes. For a software breakpoint, LENGTH specifies the size of the instruction to be patched. For hardware breakpoints and watchpoints LENGTH specifies the memory region to be monitored. reply `E'NN for an error reply `OK' for success `' If not supported. ---------------------- current Z/Z packet ---------------------- Some fragment of my code is shown below. I will follow snapshot specification(I will modify my code to adjust snapshot specification) such like.... B -> Z w -> 2 r -> 3 a -> 4 ---------------------- cut cut cut ---------------------- int v850_insert_watchpoint(addr,len,type) int addr, len, type; { char buf[PBUFSIZ], *p; struct breakpoint *b, *tmp; /* breakpoint.c */ int ignore_count; /* see breakpoint.h */ value_ptr v; /* see breakpoint.h */ int watch_addr; /* construct "Bw"<memaddr>","<len>","<ignore_count>" if type == 0 */ /* construct "Br"<memaddr>","<len>","<ignore_count>" if type == 1 */ /* construct "Ba"<memaddr>","<len>","<ignore_count>" if type == 2 */ /* sprintf (buf, "Bx%lx,%x,%x", (unsigned long) memaddr, len, ignore); */ p = buf; *p++ = 'B'; if (type == 0) *p++ = 'w'; else if (type == 1) *p++ = 'r'; else if (type == 2) *p++ = 'a'; else error ("(_o_) sorry...watchpoint has wrong value for 'type' "); p += hexnumstr (p, (ULONGEST) addr); *p++ = ','; p += hexnumstr (p, (ULONGEST) len); *p++ = ','; ignore_count = 0; ALL_BREAKPOINTS_SAFE(b, tmp) { if (b->exp != NULL) { v = evaluate_expression (b->exp); watch_addr = VALUE_ADDRESS(v) + VALUE_OFFSET(v); if ( watch_addr == addr) { ignore_count = b->ignore_count; b->ignore_count = 0; break; } } } p += hexnumstr (p, (ULONGEST) ignore_count); *p++ = ':'; *p = '\0'; putpkt (buf); getpkt (buf, 0); return 0; /* 0 when success, -1 when failure */ } ---------------------- cut cut cut ---------------------- Best regards, Fukuda, M From ac131313@cygnus.com Wed Sep 22 23:16:00 1999 From: Andrew Cagney <ac131313@cygnus.com> To: gdb@sourceware.cygnus.com Subject: Context attached to a command? Date: Wed, 22 Sep 1999 23:16:00 -0000 Message-id: <37E9C499.19EF2B1E@cygnus.com> X-SW-Source: 1999-q3/msg00374.html Content-length: 458 Hello, Do any of the existing command.h functions allow you to associate some sort of context with the command? For instance, add_cmd() takes a function callback(char*arg, int from_tty); the assumption being that the function can pick up any relevant data from globals. Is there an equivalent: calloback(void *context, char *arg, int from_tty); where ``context'' was passed to the original add_command? If not, I'll add it. Andrew From jtc@redback.com Thu Sep 23 13:53:00 1999 From: jtc@redback.com (J.T. Conklin) To: Masahiro Fukuda <masahiro@lsi.nec.co.jp> Cc: gdb@sourceware.cygnus.com Subject: Re: one proposal ... `Z'T`,'ADDR`,'LENGTH`,'IGNORE_COUNT ?? Date: Thu, 23 Sep 1999 13:53:00 -0000 Message-id: <5mg1051hdv.fsf@jtc.redbacknetworks.com> References: <199909220933.SAA06550@mctcs13.ucom.lsi.nec.co.jp> X-SW-Source: 1999-q3/msg00375.html Content-length: 2635 >>>>> "Masahiro" == Masahiro Fukuda <masahiro@lsi.nec.co.jp> writes: Masahiro> My name is Masahiro Fukuda. Independently, I added some Masahiro> keyword (actually [B/b] just like J.T.C did) into gdb serial Masahiro> protocol in order to transmit "breakpoint" to gdbserver Masahiro> instead of writing TRAP instruction. Masahiro> Some arguements including <addr>, <length>, <ignore_count> Masahiro> follow breakpiont keyword in my code. Those command packets Masahiro> are generated in v850_insert_hw_breakpint()/ Masahiro> v850_insert_watchpoint() in v850-tdep.c. I didn't think about breakpoints with ignore counts when developing the breakpoint extension proposal. I did want to allow the stub to manage thread specific breakpoints, which are similar. I also spent some time thinking about how to support conditional breakpoints. My current thoughts are to use an easily parsed stack based expression syntax, but I'm not actively pursuing this feature. The problem with breakpoints with ignore counts is the synchronization of the count between GDB and the stub. As I understand your proposal, you address this by having the 'remove breakpoint' command return how many counts are left for each breakpoint. Unfortunately, I believe that this conflicts with another project that I'm working on. I've been changing GDB so that breakpoints are not inserted or removed from the target unless it is absolutely necessary to do so. At present, whenever you step through code, the active breakpoints are inserted, the code is executed, then the breakpoints are removed. If the user is using a lot of breakpoints, this greatly increases the time it takes to step through code. If GDB must sync ignore counts by removing breakpoints, that precludes this optimization. Perhaps an additional command that lists managed breakpoints and their ignore count (if any) is needed. Another possible problem is that our current model is that duplicate breakpoints are ignored when they are inserted. A breakpoint is uniquely defined by <type>, <addr>, <len>, and possibly <thread-id> if threads specific breakpoints are supported. But how can the stub tell the differences between two breakpoints when the only difference is the ignore count? This may require the stub to return a handle when a breakpoint is inserted so that GDB can uniquely identify it. I'm not saying this is a bad idea. Actually, this is the kind of thing a stub can keep track of fairly trivally yet greatly reduce the amount of debug protocol overhead. But I think it needs a bit more refinement. Thoughts? --jtc -- J.T. Conklin RedBack Networks From shenoy@wipinfo.soft.net Thu Sep 23 22:30:00 1999 From: "Narayan Shenoy R" <shenoy@wipinfo.soft.net> To: <gdb@sourceware.cygnus.com> Subject: Support for native Sun Workshop debugging format ... Date: Thu, 23 Sep 1999 22:30:00 -0000 Message-id: <199909240530.LAA02001@gem.wipinfo.soft.net> X-SW-Source: 1999-q3/msg00376.html Content-length: 482 We are using native WorkShop debugging format (non -xs) for building our parallel applications. gdb is known to have problems recognizing this format. Reverting to -xs format is unacceptable since each of the libraries build that way occupies close to 150 MB of space. Are there any plans on supporting native WorkShop debugging format? If so, any pointers to anyone who is working on that at present. Please help. Thanks, Shenoy Narayan Shenoy R ph: 5530034/35/36 extn. 1055 ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <37CB6DBE.2083662F@cygnus.com>]
[parent not found: <199912021414.JAA16068@mescaline.gnu.org>]
* Re: -Wmissing-prototypes ... [not found] ` <199912021414.JAA16068@mescaline.gnu.org> @ 1999-12-02 7:42 ` Andreas Jaeger 0 siblings, 0 replies; 4+ messages in thread From: Andreas Jaeger @ 1999-12-02 7:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb, Andrew Cagney, DJ Delorie >>>>> Eli Zaretskii writes: >> My current list is: >> >> --enable-build-warnings=-Werror\ >> ,-Wimplicit\ >> ,-Wreturn-type\ >> ,-Wcomment\ >> ,-Wtrigraphs\ >> ,-Wformat\ >> ,-Wparentheses\ >> ,-Wpointer-arith\ >> ,-Wmissing-prototypes\ >> ,-Woverloaded-virtual\ [...] Eli> Here are the patches for go32-nat.c to allow it to compile with all Eli> kinds of -Wfoo switches (I added switches beyond those mentioned above). Eli> +static void print_387_status (unsigned, struct env387 *); Shouldn't this be unsigned int? AFAIK the new ISO C99 standard mandates it - and it doesn't harm here. Eli> static void Eli> -print_387_status (unsigned short status, struct env387 *ep) Eli> +print_387_status (unsigned status, struct env387 *ep) Again: unsigned int Eli> + print_387_control_word ((unsigned)ep->control & 0xffff); unsigned int I didn't look at the rest, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From grante@visi.com Thu Dec 02 07:49:00 1999 From: Grant Edwards <grante@visi.com> To: William Gatliff <gatliff@haulpak.com> Cc: gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Thu, 02 Dec 1999 07:49:00 -0000 Message-id: <19991202094847.A1826@visi.com> References: <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> <384685A7.15184EB1@haulpak.com> X-SW-Source: 1999-q4/msg00418.html Content-length: 1858 On Thu, Dec 02, 1999 at 08:43:51AM -0600, William Gatliff wrote: > > Packet Structure: > > > > Simple structure, obviously originally designed to be able to be driven > > manually from a TTY. (Hence it's ASCII nature.) However, the protocol has > > evolved quite significantly and I doubt it could still be used very > > efficiently from a TTY. > > True, but it can still be *monitored* quite effectively with a TTY, And this is a Very Good Thing. Debugging the RDI target stuff was a pain because of the binary packet format. Even after adding of packet-logging routines, it still wasn't obvious what was wrong. Fortunately, I do that sort of stuff for a living and have an HP protocol analyzer sitting handy. :) Most of the features in the RDI packet protocol either don't work or aren't used, so a simpler ASCII protocol would have served just as well. An ASCII protocol also allows you to whip together a quick simulator for either end using something like expect (and netcat if you want to do TCP/IP). This can save your ass big time when trying to isolate problems. > and simple things like a ? query are still possible. If I'm using a > TTY then I'm desperate anyway, so I'm willing to put up with a > little pain. Go to a non-ASCII protocol, however, and the TTY > option is right out altogether, no matter how desperate I am! > > If efficiency/throughput is a problem, then go to ethernet. At > 10/100Mbps, even the overhead of ASCII isn't a problem for most > targets I can think of. Definitely. The RDI packet stuff is binary, but it's still only pleasant to use via Ethernet. For example, a "next" involves exchanging about a half-dozen packets, and even when they're in binary, doing it via RS-232 involves an annoyinge delay when you're used to seeing the green arrow in DDD move instantly.. -- Grant Edwards grante@visi.com From ezannoni@cygnus.com Thu Dec 02 08:31:00 1999 From: Elena Zannoni <ezannoni@cygnus.com> To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: using '-x -' to read gdb script from stdin Date: Thu, 02 Dec 1999 08:31:00 -0000 Message-id: <14406.40674.819682.91859@kwikemart.cygnus.com> References: <5miu2hhgkx.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00419.html Content-length: 2091 J.T. Conklin writes: > I updated one of our year old GDB executables a week or so ago, and > was notified that one of the scripts used by SQA failed to work. I > tracked it down to the following bit of code that was ifdef'd out > earlier this year. > > >From main.c: > /* NOTE: I am commenting this out, because it is not clear > where this feature is used. It is very old and > undocumented. ezannoni: 1999-05-04 */ > #if 0 > if (cmdarg[i][0] == '-' && cmdarg[i][1] == '\0') > read_command_file (stdin); > else > #endif > > > The script invoked gdb like this: > echo list "*$addr" | $gdb -batch -x - $file | head -1 > > [ I know, I should be using addr2line. But this script was written > before addr2line existed. ] > > Since all of our systems support /dev/stdin, I patched up our script > accordingly. But I wonder whether support for - should be reenabled. > Is there any reason why not? > > --jtc > JT, If I remember correctly, invoking gdb with '-x -' would start the command_loop() via read_command_file(), instead of via captured_command_loop(). In case of async (which is now the default), the traditional command_loop() is not called, because gdb_init() sets command_loop_hook to cli_command_loop(). So we would have started the regular command loop, even though all the necessary stuff for async was set up. Bad interactions would follow. Since that option was not documented, it was decided to get rid of it if nobody was going to be penalized. It may be still possible to clean things up but I just noticed that it is not just a matter of eliminating the #if 0, unfortunatley, because more surrounding code has also been deactivated. Using the source command works because that is invoked after the main command loop has already started. I can put this on my to do list, but it will be a while before I can get to it. Feel free to give it a try if you want. Elena > -- > J.T. Conklin > RedBack Networks From sasumner@juno.com Thu Dec 02 09:51:00 1999 From: Scott A Sumner <sasumner@juno.com> To: gdb@sourceware.cygnus.com Subject: gdb build troubles Date: Thu, 02 Dec 1999 09:51:00 -0000 Message-id: <19991201.205719.-370075.0.sasumner@juno.com> X-SW-Source: 1999-q4/msg00420.html Content-length: 1748 Hi, I'm trying to build gdb with the Cygwin 1.0 CD toolset for an m68k target. Here's what I do: bash-2.03$ ../gdb-4.18/configure --target=m68k-coff And here's what happens: Configuring for a i586-pc-cygwin32 host. # post-target: intl mmalloc libiberty opcodes bfd readline gash db tcl tk tcl8.1 tk8.1 tclX it cl tix libgui byacc flex bison binutils ld gas gcc sim gdb make patch prms send- pr gprof gdbtest tgas etc expect dejagnu ash bash bzip2 m4 autoconf automake lib tool ispell grep diff rcs cvssrc fileutils shellutils time textutils wdiff find emacs emacs19 uudecode hello tar gzip indent recode release sed utils guile perl apache inet gawk findutils snavigator libtool gettext zip libtermcap dosrel grep: (standard input): Permission denied (EACCES) grep: (standard input): Permission denied (EACCES) intl mmalloc libiberty opcodes bfd readline gash db tcl tk tcl8.1 tk8.1 tclX it cl tix libgui byacc flex bison binutils ld gas gcc sim gdb make patch prms send- pr gprof gdbtest tgas etc expect dejagnu ash bash bzip2 m4 autoconf automake lib tool ispell grep diff rcs cvssrc fileutils shellutils time textutils wdiff find emacs emacs19 uudecode hello tar gzip indent recode release sed utils guile perl apache inet gawk findutils snavigator libtool gettext zip libtermcap dosrel grep: (standard input): Permission denied (EACCES) grep: (standard input): Permission denied (EACCES) <REPEATS FOREVER ANNOYINGLY SPINNING THE FLOPPY DRIVE> Can anyone give me a hint as to my problem? Scott A. Sumner ___________________________________________________________________ Get the Internet just the way you want it. Free software, free e-mail, and free Internet access for a month! Try Juno Web: http://dl.www.juno.com/dynoget/tagj . From jtc@redback.com Thu Dec 02 10:36:00 1999 From: jtc@redback.com (J.T. Conklin) To: Elena Zannoni <ezannoni@cygnus.com> Cc: gdb@sourceware.cygnus.com Subject: Re: using '-x -' to read gdb script from stdin Date: Thu, 02 Dec 1999 10:36:00 -0000 Message-id: <5m4se1mbq3.fsf@jtc.redbacknetworks.com> References: <5miu2hhgkx.fsf@jtc.redbacknetworks.com> <14406.40674.819682.91859@kwikemart.cygnus.com> X-SW-Source: 1999-q4/msg00421.html Content-length: 1367 >>>>> "Elena" == Elena Zannoni <ezannoni@cygnus.com> writes: Elena> Since that option was not documented, it was decided to get rid Elena> of it if nobody was going to be penalized. It may be still Elena> possible to clean things up but I just noticed that it is not Elena> just a matter of eliminating the #if 0, unfortunatley, because Elena> more surrounding code has also been deactivated. Elena> I can put this on my to do list, but it will be a while before Elena> I can get to it. Feel free to give it a try if you want. There's no rush. Using /dev/stdin works for now, and I hope to adapt the script to use binutils' addr2line utility in the near future. After thinking this over a bit, reading commands from stdin may not be the best way to support 'command line' batch scripting. Perhaps it should be done with a command line option instead. Maybe something like this: gdb -batch --eval "list *$addr" The current command interpreter doesn't have a statement separator so that multiple commands can be put on one line, but it may be possible to add one. I tried appending a semicolon to a handful of commands and they all bailed out with syntax errors of one sort or another. Something to think about. Since my immediate problem has been solved, I'm going to put this on the back burner. --jtc -- J.T. Conklin RedBack Networks From davidwilliams@ozemail.com.au Thu Dec 02 10:49:00 1999 From: David Williams <davidwilliams@ozemail.com.au> To: "'gdb mail list'" <gdb@sourceware.cygnus.com> Subject: exceptionHandler for 68K Date: Thu, 02 Dec 1999 10:49:00 -0000 Message-id: <01BF3D51.ED385300.davidwilliams@ozemail.com.au> X-SW-Source: 1999-q4/msg00422.html Content-length: 418 Hi all, Has anyone got an example of the exceptionHandler() function for the 68K (plain old 68000 core). The m68k-stub.c module requires one (as explained in GDB manual). However it appears that this function must use its own special vector table to help identify the vector number (using return address magic!). It would just be nice to see some source code to clarify some issues for me. TIA David Williams. From davidwilliams@ozemail.com.au Thu Dec 02 10:55:00 1999 From: David Williams <davidwilliams@ozemail.com.au> To: "'gdb mail list'" <gdb@sourceware.cygnus.com> Subject: gdb stack in stub Date: Thu, 02 Dec 1999 10:55:00 -0000 Message-id: <01BF3D52.CD93EEA0.davidwilliams@ozemail.com.au> X-SW-Source: 1999-q4/msg00423.html Content-length: 596 Hi all, I noticed that a 10K local stack is allocated in the m68k-stub.c for it own use when communcating with gdb. This seems excessive. I would like to leave the stub code in my final application so that I can debug in the field (via a special option). However it would be better if the stub consumed the least amount of system resources as possible. Is there any problem with using my applications stack (if enough room is allocated for GDB usage in addition to normal usage)? My application always runs in supervisor mode. What is likely max stack usage of GDB? TIA David Williams. From jtc@redback.com Thu Dec 02 11:12:00 1999 From: jtc@redback.com (J.T. Conklin) To: "davidwilliams@ozemail.com.au" <davidwilliams@ozemail.com.au> Cc: "'gdb mail list'" <gdb@sourceware.cygnus.com> Subject: Re: gdb stack in stub Date: Thu, 02 Dec 1999 11:12:00 -0000 Message-id: <5mvh6hkvi6.fsf@jtc.redbacknetworks.com> References: <01BF3D52.CD93EEA0.davidwilliams@ozemail.com.au> X-SW-Source: 1999-q4/msg00424.html Content-length: 1636 >>>>> "David" == David Williams <davidwilliams@ozemail.com.au> writes: David> Hi all, I noticed that a 10K local stack is allocated in the David> m68k-stub.c for it own use when communcating with gdb. This David> seems excessive. I would like to leave the stub code in my David> final application so that I can debug in the field (via a David> special option). However it would be better if the stub David> consumed the least amount of system resources as possible. David> David> Is there any problem with using my applications stack (if David> enough room is allocated for GDB usage in addition to normal David> usage)? My application always runs in supervisor mode. Yes. The problem occurs when you attempt an inferior function call. GDB starts constructing a dummy stack frame at the saved stack ptr, which overwrites the stack memory being used by the stub itself. David> What is likely max stack usage of GDB? The stub code itself doesn't use much stack, but the user-supplied putDebugChar() and getDebugChar() functions might. I typically do i/o with loops polling UART registers, which isn't stack intensive. I've measured stack use of our PowerPC based stub at less than 100 bytes. A CPU like the m68k where function arguments and return addresses are passed on the stack may take a bit more. You might want to allocate a stack you know will be big enough, initialize it with a given pattern, use the stub for a while and then, examine the stack to determine where the pattern has been overwritten. That should give you a good idea how to size the stack in your system. --jtc -- J.T. Conklin RedBack Networks From jtc@redback.com Thu Dec 02 15:04:00 1999 From: jtc@redback.com (J.T. Conklin) To: "davidwilliams@ozemail.com.au" <davidwilliams@ozemail.com.au> Cc: "'gdb mail list'" <gdb@sourceware.cygnus.com> Subject: Re: exceptionHandler for 68K Date: Thu, 02 Dec 1999 15:04:00 -0000 Message-id: <5mr9h5kkt7.fsf@jtc.redbacknetworks.com> References: <01BF3D51.ED385300.davidwilliams@ozemail.com.au> X-SW-Source: 1999-q4/msg00425.html Content-length: 1692 >>>>> "David" == David Williams <davidwilliams@ozemail.com.au> writes: David> Has anyone got an example of the exceptionHandler() function David> for the 68K (plain old 68000 core). The m68k-stub.c module David> requires one (as explained in GDB manual). However it appears David> that this function must use its own special vector table to David> help identify the vector number (using return address David> magic!). It would just be nice to see some source code to David> clarify some issues for me. Although the debug stubs distributed with GDB can be used without modification, there is no reason why you must do so. Exception handling mechanisms are target dependent. If you're happy with the exception mechanism you are currently using (or the one you have designed, if you're not that far), In my opinion it is better to adapt the debug stubs exception handler installation code rather than to force your system to match. All that being said... It's been a long time since I've used the m68k, but if I remember correctly the addresses of exception handlers are stored in a 256 entry table, the address of which is stored in a exception vector table base register. In C, you might do something like this to install an address: void *exc_tbl[256]; void exceptionHandler(int vec, void *addr) { exc_tbl[vec] = addr; } In assembly, the code might be something like this: # # Inputs: # d0 - vector # d1 - address of exception handler # a0 - address of exc_tbl # move.l %d1,(%a0,%d0.l*4) Hope this helps, --jtc -- J.T. Conklin RedBack Networks From davidwilliams@ozemail.com.au Thu Dec 02 15:15:00 1999 From: David Williams <davidwilliams@ozemail.com.au> To: "'gdb mail list'" <gdb@sourceware.cygnus.com> Subject: RE: exceptionHandler for 68K Date: Thu, 02 Dec 1999 15:15:00 -0000 Message-id: <01BF3D76.F8F982C0.davidwilliams@ozemail.com.au> X-SW-Source: 1999-q4/msg00426.html Content-length: 3671 Hi, Although the debug stubs distributed with GDB can be used without modification, there is no reason why you must do so. Exception handling mechanisms are target dependent. If you're happy with the exception mechanism you are currently using (or the one you have designed, if you're not that far), In my opinion it is better to adapt the debug stubs exception handler installation code rather than to force your system to match. Good Advice, and in fact what I was already considering. However I wish to understand the exisiting m68k-stub.c better to decide if what is being done is useful and worth adapting. Please note my target (68EZ328) has a 68000 core, not CPU32, so when exceptions occur there is no vector number stored on the stack. I get the idea of what the m68k-stub.c (supplied with gdb4.18) is trying to do without understanding the full detail. The 68000 does not provide the vector number when an exception occurs. To get arround this the stub assumes that you orgainise the real 68K vectors to point to a table of 'jsr handler' op-codes. Then when the exception occurs the CPU stacks the current PC(program counter) and SR(status register) looks up the vector and loads the PC with the value in the vector. The new PC will be somewhere in the jsr table. The CPU then executes the jsr in the table which causes the CPU to stack the return address (location in the jsr table) and then jump to the exception handler. My problem is that I dont understand where this table of jsr's is located... The m68k-stub has code to determine the exception number by taking the return address on the stack (the return address is the location in the jsr table) and adding 1530 and then dividing by 6. The relevent comments in the source are "Some explanation is probably necessary to explain how exceptions are handled. When an exception is encountered the 68000 pushes the current program counter and status register onto the supervisor stack and then transfers execution to a location specified in it's vector table. The handlers for the exception vectors are hardwired to jmp to an address given by the relation: (exception - 256) * 6. These are decending addresses starting from -6, -12, -18, ... By allowing 6 bytes for each entry, a jsr, jmp, bsr, ... can be used to enter the exception handler. Using a jsr to handle an exception has an added benefit of allowing a single handler to service several exceptions and use the return address as the key differentiation. The vector number can be computed from the return address by [ exception = (addr + 1530) / 6 ]. The sole purpose of the routine _catchException is to compute the exception number and push it on the stack in place of the return address. The external function exceptionHandler() is used to attach a specific handler to a specific m68k exception." Any help would be appreciated. All that being said... It's been a long time since I've used the m68k, but if I remember correctly the addresses of exception handlers are stored in a 256 entry table, the address of which is stored in a exception vector table base register. In C, you might do something like this to install an address: void *exc_tbl[256]; void exceptionHandler(int vec, void *addr) { exc_tbl[vec] = addr; } In assembly, the code might be something like this: # # Inputs: # d0 - vector # d1 - address of exception handler # a0 - address of exc_tbl # move.l %d1,(%a0,%d0.l*4) Thanks for the code, unfortunately this does not address my problem - see notes above. From sbjohnson@ozemail.com.au Thu Dec 02 16:19:00 1999 From: Steven Johnson <sbjohnson@ozemail.com.au> To: gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Thu, 02 Dec 1999 16:19:00 -0000 Message-id: <38470CC1.1B0E5C27@ozemail.com.au> References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> <384685A7.15184EB1@haulpak.com> X-SW-Source: 1999-q4/msg00427.html Content-length: 5990 William Gatliff wrote: > > Steven Johnson wrote: > > > Packet Structure: > > > > Simple structure, obviously originally designed to be able to be driven > > manually from a TTY. > > True, but it can still be *monitored* quite effectively with a TTY, and > simple things like a ? query are still possible. Im not criticizing or suggesting a change, im making an observation. Whether $ or STX or some other packet structure is used is of little import. Advantageously, the GDB packet structure is complete and independent from the message it contains. Which is a good thing. This is very different from many "proprietary" binary protocols i've used where the packet and message are confused and mingled, so that there is no good separation of packet handling and messaging. I actually found this a nice surprise, from all of the protocols i've dealt with few people seem to realize the importance of this in good comms design. > > If efficiency/throughput is a problem, then go to ethernet. > I wasn't suggesting it was in-efficient to use from a program. I was making the general statement that it would be difficult to debug a target just using a TTY and a target with the stub. Efficiency meant, time in working out the message to key in and deciphering the response. You have no arguments from me that being able to easily observe the message stream for the purposes of debugging an implementation is a good thing. > > Good suggestions, but I would prefer that these be general stub design > guidelines that aren't enforced by gdb. Let gdb be as flexible as > possible, so that it will work with super-smart stubs that do all the > timing stuff properly, as well as stubs that are minimally written. > Yes, here's the issue. The document is completely lacking in stub implementation guidelines. IMHO, there needs to be a section of the protocol (or comments throughout it) that give this sort of information and advice to implementers of stubs. An implementer can then take it or leave it, but at least the document needs to advise how a well behaved stub could/should operate. There needs to be more than just "Here is a Packet", there also needs to be documentation along the lines of "Here is a Packet, a receiver should do this when it gets it. Possible problems in reception are, some solutions to these problems are." It would add meat to the bones that are currently described and aid in the implementation/debugging of a stub. > > Gdb is supposed to be a debugging aid; I would prefer that all the protocol > stuff not get in the way of its fundamental mission. > I'm not suggesting it does. > Also, how do you measure byte times on most debugging hosts, particularly > at 115K (my bit rate of choice) and higher? >....<snip> > No arguments here either, I was speculating about possible solutions. I wasn't saying this must be done. I would agree there are many ways to skin that cat, and some are easier than others, depending on your host. I also recognize that stubs probably don't do this now and the world hasn't come to an end. > > There is no documentation of the recovery procedure, Does GDB retransmit > > if its message is responded to with a NAK? If not, what does it do? How > > is the target supposed to identify and handle retransmits from GDB. > > > What happens if something other than + or - is received when ACK/NAK is > > expected. (For example $). > > >From my own experience, remote.c is kinda fragile where stuff like this is > concerned. I had been intending to look into this myself next year, but by > then someone else will have certainly beaten me to it. I think some > improvements have already been made. > I see this as a far more important issue than the timeout stuff, although they are related. Remote.c is probably fragile, because there is no documentation on how it should work. It wouldn't surprise me if there was inconsistency of the implementation in GDB because of this. > > Character Escaping: The mechanism of Escaping the characters is not > > defined. Further it is only defined as used by write mem binary. > > That's because this is the only place where it is needed, AFAIK. And, > since X is optional (and support for it is detected automatically by gdb), > that means that I don't have to implement it if I don't want to. Bonus for > super-minimal stubs. > Again I agree with this. I was making the observation that Character Escaping is likely to become more prevalent as the protocol evolves. To define character escaping around one message could create a situation where different messages that require it implement different mechanisms. There is evidence of that occurring in other messages, like the ':' shouldn't be used, but some messages do statement. What would probably be more appropriate is to state how escaping is performed where required as part of the base level protocol. Then in the message put a statement like, "This message contains binary data and must be Escaped using the standard escaping mechanism defined above". This way if you don't implement any of those messages, you don't need to implement Escaping. But it advantageous in that it defines how escaping will be used in any/all messages that require it. I think the same should be said for RLE. Maybe each message needs a check list that states what features it may use like this: My new Message U My comments on this message Uses RLE: NO Uses ESC: YES At least this would clearly state where both of these mechanisms can be used, and where they can't. Further, Im not stating any implementation should change. What Im trying to do is come to terms with the documented protocol. Identify weaknesses in that documentation and propose ways the document can be strengthened to more accurately reflect what is desired of an implementation. Steven Johnson Managing Director Neurizon Pty Ltd From shebs@cygnus.com Thu Dec 02 19:05:00 1999 From: Stan Shebs <shebs@cygnus.com> To: alexs@cygnus.co.uk Cc: gdb@sourceware.cygnus.com Subject: Re: Multi-threaded debugging within GDB & eCOS Date: Thu, 02 Dec 1999 19:05:00 -0000 Message-id: <199912030305.TAA24626@andros.cygnus.com> References: <77kid9$pqp$1@korai.cygnus.co.uk> X-SW-Source: 1999-q4/msg00428.html Content-length: 1641 From: "Alex Schuilenburg" <alexs@cygnus.co.uk> Date: Thu, 14 Jan 1999 11:04:23 -0000 Could someone describe how gdb would handle the following situation in debugging multiple threads using gdb (particularly on eCOS)? Has anyone thought of this scenario before? 1) gdb is tracking thread A, which claims a system mutex. 2) Either a context switch occurs or the user suspends thread A and switches to debugging thread B (which itself is suspended). 3) While stepping over fn calls within B, the code attempts to claim the mutex already owned by A. Hence B will never return from the call to the next temporary breakpoint until A is resumed and releases the mutex. Will gdb lock up? Is there any mechanisim to allow gdb to detect/catch this scenario and report back to the user what has happened? GDB will "lock up". More precisely, GDB will sit quietly waiting for the target to do something, not realizing that the user has caused a deadlock by manually suspending thread A. This is as expected, since GDB has no way to know that the program is in this state. In practice, the user gets impatient, hits ^C, sees the current state, and goes "oh yeah, my fault" and fixes. GDB's default behavior is to give all threads a chance to run when resuming, which generally prevents this kind of situation. We introduced the scheduler-locking flag for those cases where the user really really needs to lock out other threads, even if it might mean the thread being stepped will block. (I'd be interested to know if you have workarounds for this fundamental problem though.) Stan From qqi@world.std.com Thu Dec 02 19:14:00 1999 From: Quality Quorum <qqi@world.std.com> To: gdb@sourceware.cygnus.com Subject: gdb & wiggler Date: Thu, 02 Dec 1999 19:14:00 -0000 Message-id: <Pine.SGI.3.95.991202221018.1589A-100000@world.std.com> X-SW-Source: 1999-q4/msg00429.html Content-length: 383 Hi, I am working on the piece of code which will proived gdb-server like servies for embedded systems. I would like to allow people to use for interfacing with proprietary software (similar to gdb <->wiggler.dll interface). I would prefer to publish it under GPL, however, I have doubts whether or not interface like gdb <-> wiggler is compliant with GPL ? Thanks, Aleksey ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-12-02 22:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <Pine.SUN.3.91.991202192443.17848B-100000@is>
1999-12-02 22:19 ` -Wmissing-prototypes Andreas Jaeger
1999-11-27 18:50 -Wmissing-prototypes Andrew Cagney
1999-09-20 0:46 ` -Wmissing-prototypes Andrew Cagney
[not found] ` <37CB6DBE.2083662F@cygnus.com>
[not found] ` <199912021414.JAA16068@mescaline.gnu.org>
1999-12-02 7:42 ` -Wmissing-prototypes Andreas Jaeger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox