From mboxrd@z Thu Jan 1 00:00:00 1970 From: teg@redhat.com (Trond Eivind Glomsrød) To: Jason Merrill Cc: Per Bothner , gcc-sc@goof.com, gdb@sources.redhat.com Subject: Re: Status of Gdb support for new ABI? Date: Mon, 29 Jan 2001 12:18:00 -0000 Message-id: References: X-SW-Source: 2001-01/msg00202.html Jason Merrill writes: > >>>>> "Per" == Per Bothner writes: > > > How well does Gdb handle the new ABI? This is actually two questions: > > (1) How well does cvs trunk of Gdb handle the new ABI? > > It handles the mangling properly. I don't think there is any specific > support for the new ABI object model yet, and the dwarf2 output hasn't yet > been expanded to give the debugger a more complete idea of, say, how to > find virtual bases. > > > (2) How well does the current Gdb release handle the new ABI? > > It doesn't handle the new mangling at all. > > > I'm guessing that the answer to (1) is 'ok' and that of (2) is 'not'. > > One could argue that it is not acceptable for the current Gdb to > > be unable to (reasonably) debug C++ programs generated by the current Gcc. > > The implication is: We need to make sure Gdb 5.1 is released on > > or before GCC 3.0 is released. Is this possible? Am I wrong? > > If necessary, we could make a minor release of GDB that just updates the > demangler. That would be pretty straightforward. Could you please add the patches so it works on IA64 and alpha as well? :) -- Trond Eivind Glomsrød Red Hat, Inc. >From ac131313@cygnus.com Mon Jan 29 13:43:00 2001 From: Andrew Cagney To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: should xfer_memory vector functions perform multiple transfers? Date: Mon, 29 Jan 2001 13:43:00 -0000 Message-id: <3A75E33B.4C95C935@cygnus.com> References: <5mu26nl1cj.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00203.html Content-length: 760 "J.T. Conklin" wrote: > > In many (most? (all?)) cases, the xfer_memory vector functions will > perform multiple transfers if the size of the transfer is too large > to do in one. The high level logic in target_xfer_memory() will do > the same. (Ah, yes, that ...) > Is there a rule about whether a too-large transfer should be split by > xfer_memory vector functions or target_xfer_memory()? If it can be > done by vector functions, the value of target_xfer_memory_partial() > is limited. (target_xfer_memory_partial() is used (indirectly) in > generic_load() so that GDB is not completely stalled during large > transfers. My strong preference is for the target_xfer() to just move as much data as can be copied in a single atomic operation. Andrew >From ac131313@cygnus.com Mon Jan 29 13:46:00 2001 From: Andrew Cagney To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: remote protocol extension for memory access width Date: Mon, 29 Jan 2001 13:46:00 -0000 Message-id: <3A75E406.347480D4@cygnus.com> References: <5md7dbkr6i.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00204.html Content-length: 197 Side topic. If the attributes are going to be nailed down then perhaphs segments should also be included as a guideline. Hmm, perhaphs better, we can just make the segment an attribute. Andrew >From ac131313@cygnus.com Mon Jan 29 13:48:00 2001 From: Andrew Cagney To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: remote protocol extension for step out of range Date: Mon, 29 Jan 2001 13:48:00 -0000 Message-id: <3A75E47C.D2419ADA@cygnus.com> References: <5mwvbjj7k8.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00205.html Content-length: 851 "J.T. Conklin" wrote: > Step-out-of-range only commands might look like: > > ENN,SS..SS,EE..EE[,AA...AA] > or: > eSS...SS,EE..EE[,AA..AA] > > Which would step from the PC and repeat until it moved out of the > range described by SS..SS and EE..EE. I've also preserved the ability > to set the initial PC like the existing step commands for parallelism; > I don't expect that GDB will use it either. > > To be able to successfully probe for this command, there should be a > return value. An OK or EXX response should do. Older stubs would > return "" as they do for all unrecognized commands. > > Btw, I chose 'E/e' because that was the only letter in the word 'step' > that isn't already used. Would an addition to the breakpoint packet work? Rather than break when in this range, break when outside of this range. Andrew >From ac131313@cygnus.com Mon Jan 29 13:52:00 2001 From: Andrew Cagney To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: remote protocol extension for memory access width Date: Mon, 29 Jan 2001 13:52:00 -0000 Message-id: <3A75E55D.696C4303@cygnus.com> References: <5md7dbkr6i.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00206.html Content-length: 311 "J.T. Conklin" wrote: > Rather than add new commands, my thought is to add attribute support > like: > mAA..AA,LLLL[,attr=val[,attr=val[,...]]] > MAA..AA,LLLL[,attr=val[,attr=val[,...]]]:DDDD... How do you expect to detect the presence or lack of support for this in a remote target? Andrew >From ac131313@cygnus.com Mon Jan 29 13:56:00 2001 From: Andrew Cagney To: Jason Merrill Cc: Per Bothner , gcc-sc@goof.com, gdb@sources.redhat.com Subject: Re: Status of Gdb support for new ABI? Date: Mon, 29 Jan 2001 13:56:00 -0000 Message-id: <3A75E680.194E1CE7@cygnus.com> References: X-SW-Source: 2001-01/msg00207.html Content-length: 161 Jason Merrill wrote: > If necessary, we could make a minor release of GDB that just updates the > demangler. That would be pretty straightforward. Who could? >From jtc@redback.com Mon Jan 29 14:21:00 2001 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: remote protocol extension for step out of range Date: Mon, 29 Jan 2001 14:21:00 -0000 Message-id: <5mn1caf19k.fsf@jtc.redback.com> References: <5mwvbjj7k8.fsf@jtc.redback.com> <3A75E47C.D2419ADA@cygnus.com> X-SW-Source: 2001-01/msg00208.html Content-length: 1524 >>>>> "Andrew" == Andrew Cagney writes: >> Step-out-of-range only commands might look like: >> >> ENN,SS..SS,EE..EE[,AA...AA] >> or: >> eSS...SS,EE..EE[,AA..AA] >> >> Which would step from the PC and repeat until it moved out of the >> range described by SS..SS and EE..EE. I've also preserved the ability >> to set the initial PC like the existing step commands for parallelism; >> I don't expect that GDB will use it either. >> >> To be able to successfully probe for this command, there should be a >> return value. An OK or EXX response should do. Older stubs would >> return "" as they do for all unrecognized commands. >> >> Btw, I chose 'E/e' because that was the only letter in the word 'step' >> that isn't already used. Andrew> Would an addition to the breakpoint packet work? Rather than Andrew> break when in this range, break when outside of this range. If we tried, we could probably come up with something that would work. However, the point at which we know the bounds of the step region is "right before" we issue the step command. If we were to use a varient of the breakpoint packet, we'd have to issue two commands. I'd rather avoid this unnecessary command/response latency. After all, that is the primary reason for this extension. The only other option that appeals to me is to completely depricate the step command and have a new command that supports either step or step out of range depending on its arguments. --jtc -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Mon Jan 29 17:18:00 2001 From: Andrew Cagney To: Grant Edwards Cc: gdb@sources.redhat.com Subject: Re: can't print structures w/ 5.0 (worked w/ 4.18) Date: Mon, 29 Jan 2001 17:18:00 -0000 Message-id: <3A7615CF.89C65F36@cygnus.com> References: <20000928171514.A1226@visi.com> X-SW-Source: 2001-01/msg00209.html Content-length: 505 Grant Edwards wrote: > > Using gdb 5.0 (insight), I can no longer print structures. > > (gdb) print serverState > > In 4.18, it prints out the elements of serverState (it's an > array of structures). With 5.0, It just prints a number. > > Both of these are arm-elf target built on Inte RH6.2 > > Why won't 5.0 print structures? FYI, For someone to figure out what the problem is, a lot more information is going to be needed. For instance a simple test program, the exact compiler used. Andrew >From grante@visi.com Mon Jan 29 17:20:00 2001 From: Grant Edwards To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: can't print structures w/ 5.0 (worked w/ 4.18) Date: Mon, 29 Jan 2001 17:20:00 -0000 Message-id: <20010129192430.A21301@visi.com> References: <20000928171514.A1226@visi.com> <3A7615CF.89C65F36@cygnus.com> X-SW-Source: 2001-01/msg00210.html Content-length: 664 On Mon, Jan 29, 2001 at 05:15:59PM -0800, Andrew Cagney wrote: > > Using gdb 5.0 (insight), I can no longer print structures. > > > > (gdb) print serverState > > > > In 4.18, it prints out the elements of serverState (it's an > > array of structures). With 5.0, It just prints a number. > > > > Both of these are arm-elf target built on Inte RH6.2 > > > > Why won't 5.0 print structures? > > For someone to figure out what the problem is, a lot more information is > going to be needed. For instance a simple test program, the exact > compiler used. I'll try to come up with a small program that duplicates the problem. -- Grant Edwards grante@visi.com >From fjh@cs.mu.oz.au Mon Jan 29 21:25:00 2001 From: Fergus Henderson To: gcc@gcc.gnu.org, gdb@sources.redhat.com, mercury-developers@cs.mu.oz.au Subject: gdb & Mercury (was: live range splitting) Date: Mon, 29 Jan 2001 21:25:00 -0000 Message-id: <20010130162502.A27072@hg.cs.mu.oz.au> References: <20010130035143.596FD34D80@nile.gnat.com> X-SW-Source: 2001-01/msg00211.html Content-length: 4432 This originated on the gcc list. I'm cross-posting to the gdb and mercury-developers lists. On 29-Jan-2001, dewar@gnat.com wrote: > < break gdb seems like a very bad idea, since gdb is in most cases > pretty useless for ordinary Mercury developers. The main problem is > that gdb doesn't know how to print out Mercury data structures. > >> > > Two comments. > > 1. You could certainly make GDB Mecury data structure aware, as we have > for GNAT. (we are working hard on getting these patches checked into the > main gdb tree ASAP). It would certainly be *possible*. The question is whether the large amount of effort required to do so would be worth it. Since gdb doesn't understand Mercury's nondet procedures, merely fixing it to understand Mercury data structures still wouldn't be satisfactory. I suspect that getting gdb to handle Mercury data structures will be quite difficult, because of two aspects of Mercury which AFAIK are not present in any of the languages that gdb currently supports: 1. Tagged pointers. The Mercury compiler represents discriminated unions using the low bits of word-aligned pointers as tag bits. 2. Parametric polymorphism. Mercury supports parametric polymorphism with shared code (unlike e.g. C++ templates). In the code that we generate, the *type* of one parameter can depend on the *value* of another parameter. Furthermore, mdb supports a `retry' command, which allows you to restart a function call after it just has returned. This feature is so useful that it is considered almost essential. gdb doesn't support this, and adding it would be a non-trivial task. Finally, the Mercury compiler has a number of different back-ends. The GCC back-end is just one of those. It makes more sense for us to work on a debugger that will support all our different back-ends, or at least as many as possible, rather than working on which will only support the GCC back-end. The advantage of using gdb is that work done on it is amortized over different languages, but for us it may make better sense to amortize over different back-ends. > 2. Even if that is not done, it is quite wrong to think that gdb is > not usable. A very common debugging technique is to write debug > callable routines that write out results at an appropriate level > of abstraction (e.g. when debugging the gcc backend, you do not > dump raw tree structures, you use the appropriate debug routines). I have used that technique when debugging the Mercury compiler. Indeed the Mercury standard library provides a routine that will print out any value, given the value and the appropriate type descriptor. However, figuring out the type descriptors by hand is very hard, even for me, and if you get it wrong the result is a seg fault, which generally means you have to restart debugging from the start of the program. I would not want to recommend this technique to ordinary Mercury programmers. `mdb' is much much easier to use. > < format of debug information that we put in the executable as ordinary > read-only static constants (i.e. .rodata). We plan to adapt mdb to > work with the GCC back-end version of the Mercury compiler. > >> > > Surely it would be much better to use an appropriate Dwarf-2 section. > You don't want to unconditionally load debug data. That would only be portable to systems that use Dwarf-2. Putting the debug info in ordinary read-only static constants is more portable. With demand loading, the cost of this is not so bad. And you only pay it when you compile with debugging enabled. Actually our debugging scheme has some other costs which are worse. But note that for debugging you want to inhibit tail recursion and sibling call optimization, so performance of Mercury programs compiled with debugging enabled is never going to be great anyway. P.S. If you want to know more about the Mercury debugger, there's a paper "The implementation technology of the Mercury debugger" on our web site at < http://www.cs.mu.oz.au/mercury/information/papers.html >. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: < http://www.cs.mu.oz.au/~fjh > | -- the last words of T. S. Garp. >From dewar@gnat.com Mon Jan 29 22:02:00 2001 From: dewar@gnat.com To: fjh@cs.mu.oz.au, gcc@gcc.gnu.org, gdb@sources.redhat.com, mercury-developers@cs.mu.oz.au Subject: Re: gdb & Mercury (was: live range splitting) Date: Mon, 29 Jan 2001 22:02:00 -0000 Message-id: <20010130060215.A446534D80@nile.gnat.com> X-SW-Source: 2001-01/msg00212.html Content-length: 219 <> I think that all systems support Dwarf-2 in the sense that matters here .. >From jason@redhat.com Tue Jan 30 04:32:00 2001 From: Jason Merrill To: Andrew Cagney Cc: Per Bothner , gdb@sources.redhat.com Subject: Re: Status of Gdb support for new ABI? Date: Tue, 30 Jan 2001 04:32:00 -0000 Message-id: References: <3A75E680.194E1CE7@cygnus.com> X-SW-Source: 2001-01/msg00213.html Content-length: 279 >>>>> "Andrew" == Andrew Cagney writes: > Jason Merrill wrote: >> If necessary, we could make a minor release of GDB that just updates the >> demangler. That would be pretty straightforward. > Who could? Er, my wonderful friends on the GDB team. Jason >From ac131313@cygnus.com Tue Jan 30 11:33:00 2001 From: Andrew Cagney To: Jason Merrill Cc: Per Bothner , gdb@sources.redhat.com Subject: Re: Status of Gdb support for new ABI? Date: Tue, 30 Jan 2001 11:33:00 -0000 Message-id: <3A771649.48A38590@cygnus.com> References: <3A75E680.194E1CE7@cygnus.com> X-SW-Source: 2001-01/msg00214.html Content-length: 844 Jason Merrill wrote: > > >>>>> "Andrew" == Andrew Cagney writes: > > > Jason Merrill wrote: > >> If necessary, we could make a minor release of GDB that just updates the > >> demangler. That would be pretty straightforward. Mumble something about debug info. > > Who could? > > Er, my wonderful friends on the GDB team. Roll on floor laughing. The 5.0 branch is about a year old so you're not going to get a straight forward mini-release out of that. Besides, C++ support in 5.0 sucked. The most useful thing that could happen is for GCC's C++ group to test current GCC against current GDB and then help track the two (by submitting patches). That way if/when a 5.1 release is done it is going to be close to working. At present Dan, the sole C++ GDB maintainer, is only just managing to tread water. Andrew >From ac131313@cygnus.com Tue Jan 30 12:19:00 2001 From: Andrew Cagney To: James Cownie Cc: gdb@sourceware.cygnus.com, Jamie Guinan Subject: Re: Asynchronous GDB Date: Tue, 30 Jan 2001 12:19:00 -0000 Message-id: <3A772124.14D58AD6@cygnus.com> References: <14EU7B-0mE-00@etnus.com> X-SW-Source: 2001-01/msg00215.html Content-length: 600 > In other words the only thing you can do via ptrace to an unstopped > process is kill it. Unless the target has several processes and one is dedicated to debugging that will always be the case. Some code somewhere will need to stop the system just long enough to capture the required information and then resume it. The main thing is that it is pushed down towards the target and away from the debug core. In terms of async debugging, its been demoed working with single threaded remote target but not much else. There are still some fairly fundamental design problems in the way :-( Andrew >From jtc@redback.com Tue Jan 30 20:32:00 2001 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: Re: remote protocol extension for step out of range Date: Tue, 30 Jan 2001 20:32:00 -0000 Message-id: <5mvgqw8hpt.fsf@jtc.redback.com> References: <5mwvbjj7k8.fsf@jtc.redback.com> X-SW-Source: 2001-01/msg00216.html Content-length: 6175 >>>>> "jtc" == J T Conklin writes: jtc> Step-out-of-range only commands might look like: jtc> jtc> ENN,SS..SS,EE..EE[,AA...AA] jtc> or: jtc> eSS...SS,EE..EE[,AA..AA] jtc> jtc> Which would step from the PC and repeat until it moved out of the jtc> range described by SS..SS and EE..EE. I've also preserved the ability jtc> to set the initial PC like the existing step commands for parallelism; jtc> I don't expect that GDB will use it either. jtc> jtc> To be able to successfully probe for this command, there should be a jtc> return value. An OK or EXX response should do. Older stubs would jtc> return "" as they do for all unrecognized commands. It turned out to be trival to implement the above. I've enclosed a patch for review. The guts are ~50 lines, including comments. The rest is required for the CLI so the user can enable and disable the new packets. I welcome any comments, --jtc Index: remote.c =================================================================== RCS file: /cvs/src/src/gdb/remote.c,v retrieving revision 1.35 diff -c -r1.35 remote.c *** remote.c 2001/01/23 22:48:56 1.35 --- remote.c 2001/01/31 04:20:08 *************** *** 662,667 **** --- 662,701 ---- } } + /* Should we try the 'e' (step over range) request? */ + static struct packet_config remote_protocol_e; + + static void + set_remote_protocol_e_packet_cmd (char *args, int from_tty, + struct cmd_list_element *c) + { + update_packet_config (&remote_protocol_e); + } + + static void + show_remote_protocol_e_packet_cmd (char *args, int from_tty) + { + show_packet_config_cmd (&remote_protocol_e); + } + + + /* Should we try the 'E' (step over range / w signal #) request? */ + static struct packet_config remote_protocol_E; + + static void + set_remote_protocol_E_packet_cmd (char *args, int from_tty, + struct cmd_list_element *c) + { + update_packet_config (&remote_protocol_E); + } + + static void + show_remote_protocol_E_packet_cmd (char *args, int from_tty) + { + show_packet_config_cmd (&remote_protocol_E); + } + + /* Should we try the 'P' (set register) request? */ static struct packet_config remote_protocol_P; *************** *** 2030,2035 **** --- 2064,2071 ---- init_all_packet_configs (void) { int i; + update_packet_config (&remote_protocol_e); + update_packet_config (&remote_protocol_E); update_packet_config (&remote_protocol_P); for (i = 0; i < NR_Z_PACKET_TYPES; i++) update_packet_config (&remote_protocol_Z[i]); *************** *** 2293,2298 **** --- 2329,2335 ---- remote_resume (int pid, int step, enum target_signal siggnal) { char *buf = alloca (PBUFSIZ); + char *p; if (pid == -1) set_thread (0, 0); /* run any thread */ *************** *** 2307,2317 **** if (target_resume_hook) (*target_resume_hook) (); if (siggnal != TARGET_SIGNAL_0) { buf[0] = step ? 'S' : 'C'; buf[1] = tohex (((int) siggnal >> 4) & 0xf); ! buf[2] = tohex ((int) siggnal & 0xf); buf[3] = '\0'; } else --- 2344,2409 ---- if (target_resume_hook) (*target_resume_hook) (); + + /* The s/S/c/C packets do not return status. So if the target does + not support the S or C packets, the debug agent returns an empty + string which is detected in remote_wait(). This protocol defect + is fixed in the e/E packets. */ + + if (step && step_range_end) + { + /* If the target does not support the 'E' packet, we try the 'S' + packet. Ideally we would fall back to the 'e' packet if that + too is not supported. But that would require another copy of + the code to issue the 'e' packet (and fall back to 's' if not + supported) in remote_wait(). */ + + if (siggnal != TARGET_SIGNAL_0) + { + if (remote_protocol_E.support != PACKET_DISABLE) + { + p = buf; + *p++ = 'E'; + *p++ = tohex (((int) siggnal >> 4) & 0xf); + *p++ = tohex (((int) siggnal) & 0xf); + *p++ = ','; + p += hexnumstr (p, (ULONGEST) step_range_start); + *p++ = ','; + p += hexnumstr (p, (ULONGEST) step_range_end); + *p++ = 0; + + putpkt (buf); + getpkt (buf, PBUFSIZ, 0); + + if (packet_ok(buf, &remote_protocol_E) == PACKET_OK) + return; + } + } + else + { + if (remote_protocol_e.support != PACKET_DISABLE) + { + p = buf; + *p++ = 'e'; + p += hexnumstr (p, (ULONGEST) step_range_start); + *p++ = ','; + p += hexnumstr (p, (ULONGEST) step_range_end); + *p++ = 0; + + putpkt (buf); + getpkt (buf, PBUFSIZ, 0); + + if (packet_ok(buf, &remote_protocol_e) == PACKET_OK) + return; + } + } + } + if (siggnal != TARGET_SIGNAL_0) { buf[0] = step ? 'S' : 'C'; buf[1] = tohex (((int) siggnal >> 4) & 0xf); ! buf[2] = tohex (((int) siggnal) & 0xf); buf[3] = '\0'; } else *************** *** 5497,5503 **** --- 5589,5598 ---- static void show_remote_cmd (char *args, int from_tty) { + show_remote_protocol_Z_packet_cmd (args, from_tty); + show_remote_protocol_e_packet_cmd (args, from_tty); + show_remote_protocol_E_packet_cmd (args, from_tty); show_remote_protocol_P_packet_cmd (args, from_tty); show_remote_protocol_binary_download_cmd (args, from_tty); } *************** *** 5641,5646 **** --- 5736,5755 ---- add_info ("remote-process", remote_info_process, "Query the remote system for process info."); + + add_packet_config_cmd (&remote_protocol_e, + "e", "step-over-range", + set_remote_protocol_e_packet_cmd, + show_remote_protocol_e_packet_cmd, + &remote_set_cmdlist, &remote_show_cmdlist, + 0); + + add_packet_config_cmd (&remote_protocol_E, + "E", "step-over-range-w-signal", + set_remote_protocol_E_packet_cmd, + show_remote_protocol_E_packet_cmd, + &remote_set_cmdlist, &remote_show_cmdlist, + 0); add_packet_config_cmd (&remote_protocol_P, "P", "set-register", -- J.T. Conklin RedBack Networks >From joel.brenner@tchip.com Wed Jan 31 01:35:00 2001 From: Joel Brenner <joel.brenner@tchip.com> To: gdb@sources.redhat.com Subject: Does GDB suports mixed ARM_code (ARM+Thumb) debugging? Date: Wed, 31 Jan 2001 01:35:00 -0000 Message-id: <3A77DC9D.FA1C95B5@tchip.com> X-SW-Source: 2001-01/msg00217.html Content-length: 0