From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: shebs@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: PATCH to buildsym.c Date: Wed, 01 Dec 1999 14:36:00 -0000 Message-id: <19991201143603Z.mitchell@codesourcery.com> References: <19991201135115K.mitchell@codesourcery.com> <199912012219.OAA18447@andros.cygnus.com> X-SW-Source: 1999-q4/msg00399.html >>>>> "Stan" == Stan Shebs writes: Stan> Non-regression is good, but how is it that you're getting so Stan> many failures? Current GDB on Linux should be at about 10 Stan> fails, at least until very recently, when it went up to 30 Stan> or so because some failing thread tests got counted instead Stan> of being skipped over. 178 is bad... I dunno. I did configure/make/make check on a RH 6.1 system using /usr/bin/gcc as the compiler, and that's what happenned. It could be some kind of version skew with dejagnu, I suppose. I'll look into it a little bit. Stan> Different number means different source line, and a later Stan> source line is more likely to be inside the function, rather Stan> than on an empty line prior to the function or some such. Stan> It has the potential to be confusing to users, and also to Stan> GUIs, although it probably won't cause anything to roll over Stan> and die (unless DDD is more complicated than I think :-) ). I hear what you're saying, but I'm not really buying it. Basically, you're trying to second-guess the compiler in the debugger; it seems like pretty clear semantics to me to say last note wins. I understand that some compilers might do something bizarre (putting the good note first, and then a note for an empty line after that). If there really are such compilers, then we should maybe provide work-arounds for that. But, why do this to all compilers, even ones that are doing this on purpose? The current behavior is confusing in exactly the way you say; you get to an inline function and wind up staring at a curly brace for the caller: inline void f () { i = 3; } void g() { f() } This tends to have GDB at the opening curly brace for `g' when the last line note is pointing at `i = 3'. So, that's pretty strange. Then, stepping ends you up at the closing curly brace for `g' without ever ending up in `f'. Stan> Note that GDB has to work with different compilers, not just Stan> GCC, and so if you always have consistent handling of I understand. Stan> multiple line notes, the testing results and user-visible Stan> behavior will be uniform across compilers and compiler Stan> versions. I don't really see that, but I'll take your word for it. Different compilers are likely to emit line notes in lots of different ways. Some may never emit duplicate line notes for the same PC. But, it's hard for me to imagine compiler people intentionally emitting a line note correponding to the next instruction, then emitting another line note *not* corresponding to that instruction, and then emitting the instruction itself. That's a little odd. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com >From jimb@cygnus.com Wed Dec 01 14:43:00 1999 From: Jim Blandy To: Stan Shebs Cc: mainguen@gabin.frcl.bull.fr, gdb@sourceware.cygnus.com Subject: Re: Gdb target for kdb Date: Wed, 01 Dec 1999 14:43:00 -0000 Message-id: References: <199912010302.TAA17555@andros.cygnus.com> X-SW-Source: 1999-q4/msg00401.html Content-length: 430 > We intend to use gdb to debug a running Linux kernel connected > to another Linux box via an asynchronous line. For this purpose, > we are considering developping a new gdb target that interfaces > with kdb. Has anyone ever tried to develop such a kdb target > before ? > > Not to my knowledge. As Jim Blandy, you could pretend it's like a ROM > monitor and do a backend that way. But *only* if you're me. :) >From jimb@cygnus.com Wed Dec 01 14:43:00 1999 From: Jim Blandy To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: ST(i) and MMj Date: Wed, 01 Dec 1999 14:43:00 -0000 Message-id: 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> X-SW-Source: 1999-q4/msg00400.html Content-length: 942 > 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. :) >From jimb@cygnus.com Wed Dec 01 14:45:00 1999 From: Jim Blandy To: rok.papez@kiss.uni-lj.si Cc: gdb@sourceware.cygnus.com, gnu-gdb-bug@moderators.isc.org Subject: Re: Insight 19991116, gdbserver, fork() - always follows parent Date: Wed, 01 Dec 1999 14:45:00 -0000 Message-id: References: <99120112265800.00878@Strader.home> X-SW-Source: 1999-q4/msg00402.html Content-length: 546 I don't think follow-fork mode is implemented for Linux. > 2.) Can insight and/or gdb finally work with LinuxThreads? What about > gdbserver? Do new threads block when they get created ? The snapshots should be able to debug applications that use LinuxThreads. Release 4.18 cannot. Threads start running normally when they are created. > 4.) Is it possible to compile into the programme a breakpoint (so when it is > run I could attach to it) - if yes - how to make it work with gdbserver. You can always do something like sleep (100000). >From shebs@cygnus.com Wed Dec 01 15:01:00 1999 From: Stan Shebs To: mark@codesourcery.com Cc: gdb@sourceware.cygnus.com Subject: Re: PATCH to buildsym.c Date: Wed, 01 Dec 1999 15:01:00 -0000 Message-id: <199912012301.PAA24624@andros.cygnus.com> References: <19991201143603Z.mitchell@codesourcery.com> X-SW-Source: 1999-q4/msg00403.html Content-length: 2938 From: Mark Mitchell Date: Wed, 01 Dec 1999 14:36:03 -0800 >>>>> "Stan" == Stan Shebs writes: Stan> Non-regression is good, but how is it that you're getting so Stan> many failures? Current GDB on Linux should be at about 10 Stan> fails, at least until very recently, when it went up to 30 Stan> or so because some failing thread tests got counted instead Stan> of being skipped over. 178 is bad... I dunno. I did configure/make/make check on a RH 6.1 system using /usr/bin/gcc as the compiler, and that's what happenned. It could be some kind of version skew with dejagnu, I suppose. I'll look into it a little bit. If you point me at a gdb.{sum,log}, I could do a quick analysis. Stan> Different number means different source line, and a later Stan> source line is more likely to be inside the function, rather Stan> than on an empty line prior to the function or some such. Stan> It has the potential to be confusing to users, and also to Stan> GUIs, although it probably won't cause anything to roll over Stan> and die (unless DDD is more complicated than I think :-) ). I hear what you're saying, but I'm not really buying it. Basically, you're trying to second-guess the compiler in the debugger; it seems like pretty clear semantics to me to say last note wins. Indeed it is clear; my question is whether we can get away with specifying a detail of the compiler output that has not been specified previously. Your proposal is basically to require that compilers issue line notes in a specific order. While this is attractive for improving debug of inlined functions, it is still a change to the spec of the compiler/debugger interface, and it's a change to be more restrictive. So we need to understand if there are any compatibility pitfalls. Also, the change history suggests that when this code was last tinkered with, in 1993, Kingdon was unsure what to do here, and when Kingdon doesn't know, I tremble... :-) Stan> multiple line notes, the testing results and user-visible Stan> behavior will be uniform across compilers and compiler Stan> versions. I don't really see that, but I'll take your word for it. Different compilers are likely to emit line notes in lots of different ways. Some may never emit duplicate line notes for the same PC. But, it's hard for me to imagine compiler people intentionally emitting a line note correponding to the next instruction, then emitting another line note *not* corresponding to that instruction, and then emitting the instruction itself. That's a little odd. Yeah, well, some versions of Sun's compiler have been notable for oddity of debug output. The stabs manual mentions some amusing cases, although reassuringly, none of them involve line numbers. Stan >From sbjohnson@ozemail.com.au Wed Dec 01 15:09:00 1999 From: Steven Johnson To: gdb@sourceware.cygnus.com Subject: Standard GDB Remote Protocol Date: Wed, 01 Dec 1999 15:09:00 -0000 Message-id: <3845AB0E.3795D99E@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> X-SW-Source: 1999-q4/msg00404.html Content-length: 997 I am about to write a GDB Remote Stub, and I want to use the standard GDB Remote protocol for this. Can anyone point me at the Protocol specification for this? Or doesn't it exist? Ive looked everywhere I can think of and can find nothing documented about it, except references to the fact GDB has this standard Protocol. I Know i'll get the answer "Use the Source". But that is hardly appropriate for a Protocol. There are far more subtleties to Protocol Design and Implementation than can usually be gleaned from anyone's source code. If it doesn't exist, does anyone have any objections to a complete, formal, Protocol specification for the GDB Remote Protocol being created. (Note: here Im putting up my hand. If I have to reverse engineer it from the code, Im going to document it for my benefit anyway.) If it does exist, is it up-to-date? If I need to create one, what format should I create it in? (i.e., preferred document type). Steven Johnson Managing Director Neurizon Pty Ltd >From jtc@redback.com Wed Dec 01 15:22:00 1999 From: jtc@redback.com (J.T. Conklin) To: Steven Johnson Cc: gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Wed, 01 Dec 1999 15:22:00 -0000 Message-id: <5md7sql00o.fsf@jtc.redbacknetworks.com> 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> X-SW-Source: 1999-q4/msg00405.html Content-length: 1287 >>>>> "Steven" == Steven Johnson writes: Steven> I am about to write a GDB Remote Stub, and I want to use the standard Steven> GDB Remote protocol for this. Steven> Steven> Can anyone point me at the Protocol specification for this? Or doesn't Steven> it exist? I think the RDP specification still needs some work, but things are a lot better than they were a even few months ago. The spec has been moved from comments in remote.c to the GDB manual. Grab a snapshot from sourceware to get the most recent copy. I believe that Andrew Cagney had some changes in the queue, and I have some changes I was going to contribute once Andrew was done. Steven> If it doesn't exist, does anyone have any objections to a complete, Steven> formal, Protocol specification for the GDB Remote Protocol being Steven> created. (Note: here Im putting up my hand. If I have to reverse Steven> engineer it from the code, Im going to document it for my benefit Steven> anyway.) Since you're putting up your hand, would you be willing to review the protocol spec and point out areas that are ambiguous, confusing, need revising, etc? I'm not going to point out what I think is wrong so I won't bias you one way or the other. --jtc -- J.T. Conklin RedBack Networks >From mark@codesourcery.com Wed Dec 01 15:31:00 1999 From: Mark Mitchell To: shebs@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: PATCH to buildsym.c Date: Wed, 01 Dec 1999 15:31:00 -0000 Message-id: <19991201153132K.mitchell@codesourcery.com> References: <19991201143603Z.mitchell@codesourcery.com> <199912012301.PAA24624@andros.cygnus.com> X-SW-Source: 1999-q4/msg00407.html Content-length: 2323 >>>>> "Stan" == Stan Shebs writes: Stan> If you point me at a gdb.{sum,log}, I could do a quick Stan> analysis. OK, I'll forward this to you privately if I can't see it right off. Thanks! Stan> Indeed it is clear; my question is whether we can get away Stan> with specifying a detail of the compiler output that has not Stan> been specified previously. Your proposal is basically to Stan> require that compilers issue line notes in a specific order. Stan> While this is attractive for improving debug of inlined Stan> functions, it is still a change to the spec of the Stan> compiler/debugger interface, and it's a change to be more Stan> restrictive. So we need to understand if there are any Stan> compatibility pitfalls. We *already* specify this detail. In particular, we specify that if a compiler wants a debugger to show a particular line for a particular instruction then it must emit a line note for that instruction and *not* emit any line notes with higher numbered lines for that same instruction. We're changing the specification; on that I agree. I'd just argue that a) the old specification doesn't make much sense, and b) there are no known examples of compilers purposefully using the old specification (in particular, that emit line notes for lines that they don't intend the instruction to correspond to, but only if the line numbers are smaller than the correct line note.) Stan> Yeah, well, some versions of Sun's compiler have been Stan> notable for oddity of debug output. The stabs manual Stan> mentions some amusing cases, although reassuringly, none of Stan> them involve line numbers. I'm sure lots of compilers do lots of weird things! (I know GCC does...) I guess I'm arguing that since we know that GCC wants to do this, and since GDB is primarily used with GCC, and since we seem to agree that the change (abstractly) makes sense, and since we don't actually know that anything will be broken, that we should go for the change. If someone complains, then we can back out the patch and try to change GCC, we can make GDB do different things depending on a user-provided flag, etc. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com >From kevinb@cygnus.com Wed Dec 01 15:31:00 1999 From: Kevin Buettner To: Steven Johnson , gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Wed, 01 Dec 1999 15:31:00 -0000 Message-id: <991201233340.ZM24842@ocotillo.lan> 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> X-SW-Source: 1999-q4/msg00406.html Content-length: 298 On Dec 2, 9:11am, Steven Johnson wrote: > I am about to write a GDB Remote Stub, and I want to use the standard > GDB Remote protocol for this. > > Can anyone point me at the Protocol specification for this? Or doesn't > it exist? http://sourceware.cygnus.com/gdb/onlinedocs/gdb_14.html#IDX532 >From qqi@world.std.com Wed Dec 01 15:38:00 1999 From: Quality Quorum To: gdb@sourceware.cygnus.com Subject: bugs in remote.c Date: Wed, 01 Dec 1999 15:38:00 -0000 Message-id: X-SW-Source: 1999-q4/msg00408.html Content-length: 1898 Hi, I found a few minor bugs in remote.c (gdb-19990519), I can provide fixes if necessary. 1. remote_write_bytes - either ':' has to be escaped too or sequences have to be outlawed once and forever. 2. set_thread - ignores returned packet. 3. remote_get_threadinfo and remote_get_threadlist - assume that first two chars of the packet are fine - this one can really screw things up. 4. remote_open_1 - does not check for returned errors or non-supported extended ops. 5. Inconsitent processing of returned errors: a. Error is ignored by set_thread, remote_thread_alive, remote_get_threadinfo, remote_get_threadlist, remote_current_thread, extended_remote_restart, remote_open_1, remote_fetch_registers, check_binary_download, remote_query. b. Error is considered worth a warning by get_offsets and remote_wait. c. Error is considered fatal by remote_detach, remote_fetch_registers, remote_store_registers, compare_sections_command. d. errno = EIO is set by remote_write_bytes and remote_read_bytes. c. memory_error(EIO, startaddr) is called by remote_search. 6. Inconsistent processing of returned no-support status: a. compare_sections_command - consideres no support for the operation a fatal error. b. It is ignored by set_thread, remote_thread_alive, remote_open_1, remote_write_bytes, remote_read_bytes, remote_store_registers, remote_fecth_registers. Naturally, some of these cases are improbable, however, it does not mean that it shold not be checked to flag faulty stubs. 7. extended_remote_restart does not give target any time to do restart. 8. remote_fecth_registers is unique in a sense that it will keep trying until watchdog will be fired up. Thanks, Aleksey