From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Jaeger To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com, Andrew Cagney , DJ Delorie Subject: Re: -Wmissing-prototypes ... Date: Thu, 02 Dec 1999 07:42:00 -0000 Message-id: References: <37E5E508.D56E054C@cygnus.com> <37CB6DBE.2083662F@cygnus.com> <199912021414.JAA16068@mescaline.gnu.org> X-SW-Source: 1999-q4/msg00417.html >>>>> 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 To: William Gatliff 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> <199911251715.MAA09225@mescaline.gnu.org> <199912010821.DAA27130@mescaline.gnu.org> <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 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 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) 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 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 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 To: "'gdb mail list'" 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 To: "'gdb mail list'" 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" Cc: "'gdb mail list'" 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 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" Cc: "'gdb mail list'" 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 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 To: "'gdb mail list'" 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 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> <199911231303.IAA01523@mescaline.gnu.org> <199911251715.MAA09225@mescaline.gnu.org> <199912010821.DAA27130@mescaline.gnu.org> <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? >.... > 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 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" 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 To: gdb@sourceware.cygnus.com Subject: gdb & wiggler Date: Thu, 02 Dec 1999 19:14:00 -0000 Message-id: 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