From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Toshiyasu Morita Cc: gdb@sourceware.cygnus.com Subject: Re: breakpoint extension for remote protocol, take II Date: Mon, 14 Jun 1999 17:43:00 -0000 Message-id: <5mu2sa2t2d.fsf@jtc.redbacknetworks.com> References: <199906150023.RAA14961@netcom16.netcom.com> X-SW-Source: 1999-q2/msg00169.html >>>>> "Toshiyasu" == Toshiyasu Morita writes: >> I was unaware processors with multiple software breakpoints >> existed. I assume that the 2 byte breakpoint instructions have to >> be inserted in "high-density" code segments and 4 byte breakpoints >> insns have to be inserted in "low-density" segments. Toshiyasu> Is there a four-byte sequence which is an illegal Toshiyasu> instruction in both MIPS16 and MIPS32 modes? Even if there were, I don't think it would work. If you installed this four byte sequence in a 16 bit code segment at 0x1000, it would also overwrite the instruction at 0x1002. If that instruction is a branch target, bad things are likely to happen. A bit of compiler support to insert a nop before branch targets could possibly make this work, but that would diminish any benefit high density instructions are supposed to offer. --jtc -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Mon Jun 14 18:01:00 1999 From: Andrew Cagney To: Stan Shebs Cc: gdb@sourceware.cygnus.com Subject: Re: Testsuite Organization Proposal Date: Mon, 14 Jun 1999 18:01:00 -0000 Message-id: <3765A5CE.E9C8B0E9@cygnus.com> References: <199906142351.QAA06182@andros.cygnus.com> X-SW-Source: 1999-q2/msg00170.html Content-length: 1173 Stan Shebs wrote: > > I'd like to propose a semi-formalization of the current testsuite > organization, basically just reflecting current practice, but with > enough precision to guide further additions. The testsuite is key for > GDB developers; the breadth of functionality and platforms is now so > broad, in many cases, users won't discover regressions for months or > years after the change that caused them; while a testsuite run often > reveals mistakes right away. > > First of all, testsuite organization mainly serves the purpose of > intelligibility; DejaGNU finds all the expect scripts wherever they're > placed. But with around 6000 tests in all, it becomes important to > organize them sensibly. > > gdb.base This is the base testsuite. The tests in it should > apply to all configurations of GDB (but generic > native-only tests may live here). The test programs > should be in a subset of C that is valid K&R, ANSI/ISO, > and C++ (ifdefs are allowed). I'd kind of like to see gdb.base contain no C++ tests. There are targets out there that don't have a C++ compiler. Andrew >From ac131313@cygnus.com Mon Jun 14 18:13:00 1999 From: Andrew Cagney To: Stan Shebs Cc: jtc@redback.com, gdb@sourceware.cygnus.com Subject: Re: breakpoint extension for remote protocol, take II Date: Mon, 14 Jun 1999 18:13:00 -0000 Message-id: <3765A855.5EF176AF@cygnus.com> References: <199906142359.QAA06291@andros.cygnus.com> X-SW-Source: 1999-q2/msg00171.html Content-length: 1140 Stan Shebs wrote: > > Date: 14 Jun 1999 16:47:32 -0700 > Lines: 39 > > Bleh. But that's what the 'q' escape is for. IMO, all experimental > protocol extensions should be using 'q'; likewise, GDB should never > use 'q' itself. > > You mean like with qOffsets, that's been standardly issued by GDB for > years? :-) And QCrc. I've just had this one pointed out to me .... > Actually, I don't ever remember hearing that 'q' was supposed to be > experimental, and the existing docs don't seem to say so either. At > this point we would have to pick a different char I think, and be very > disciplined about not allowing any usages of it into the standard > sources, so that it really can be for experimentation. I'd like to seriously propose that: [qQ][A-Z].* be reserved for GDB's internal use while: [qQ][a-z].* be declared as available for custom jobs. In addition, custom packets include a clearly reconisable identifier vis: qcygnus.badhack > In general, we have a sizeable documentation gap with the remote > protocol; it's become so ubiquitous it ought to have its own RFC... :-) Comming ... Andrew >From ac131313@cygnus.com Mon Jun 14 19:00:00 1999 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: Unused remote protocol letters? Date: Mon, 14 Jun 1999 19:00:00 -0000 Message-id: <3765B333.6B886FB7@cygnus.com> References: <199906142359.QAA06291@andros.cygnus.com> X-SW-Source: 1999-q2/msg00172.html Content-length: 237 Hello, Using pencil and paper and a glance through several sources I think the following letters (upper and lower case) havn't been taken yet: a, e, f, i, j, l, n, o, u, v, w, y, z Anyone care to concure with this? Andrew >From ac131313@cygnus.com Mon Jun 14 19:15:00 1999 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: Re: Unused remote protocol letters? Date: Mon, 14 Jun 1999 19:15:00 -0000 Message-id: <3765B4B6.32B11EA7@cygnus.com> References: <199906142359.QAA06291@andros.cygnus.com> <3765B333.6B886FB7@cygnus.com> X-SW-Source: 1999-q2/msg00173.html Content-length: 426 Andrew Cagney wrote: > > Hello, > > Using pencil and paper and a glance through several sources I think the > following letters (upper and lower case) havn't been taken yet: > > a, e, f, i, j, l, n, o, u, v, w, y, z > > Anyone care to concure with this? (Following up to ones own e-mail ...) ``A'' is apparently the arguments packet... Lets try: e, f, i, j, l, n, o, u, v, w, y, z Andrew >From jsm@cygnus.com Mon Jun 14 22:59:00 1999 From: Jason Molenda To: gdb@sourceware.cygnus.com Subject: Old GDB releases are now available by anon-ftp Date: Mon, 14 Jun 1999 22:59:00 -0000 Message-id: <19990614225906.A3608@cygnus.com> X-SW-Source: 1999-q2/msg00174.html Content-length: 660 I have put a collection of old GDB releases on-line at ftp://sourceware.cygnus.com/pub/gdb/releases/ANCIENT/ I have collected GDB releases going back to GDB 2.4, released in January, 1988. I think I have most of them from about 3.4 and on. Earlier than 3.4, I'm missing many of the releasees. These old releases are completely useless on modern hardware, don't even think about using any of them. Every so often someone needs to look into an old version of GDB for some reason or another; this archive should be helpful for those people. If you have any old gdb releases sitting around that I do not have in this collection, please let me know. Jason >From brendan@dgs.monash.edu.au Tue Jun 15 17:11:00 1999 From: Brendan Simon To: binutils , Dan Malek , Magnus Damm , gdb Subject: Using objdump to force a section to load with gdb. Date: Tue, 15 Jun 1999 17:11:00 -0000 Message-id: <3766EA73.123505A6@dgs.monash.edu.au> X-SW-Source: 1999-q2/msg00175.html Content-length: 2181 I have a linux kernel compiled for a mpc860 target and am trying to get it to run by downloading it into memory using a background debugger (BDM). The boot code gets to the point where it trys to uncompress the kernel but fails because the image isn't loaded into memory (only .text, .rodata and .data are loaded). I tried using objcopy to set the "image" section to "load" but it does not seem to work. How can I get gdb to load the image section (either using a gdb command or binutils) ? Thanks, Brendan Simon. Here is a before/after trace using objcopy --set-section-flags. As you can see, the load attribute is not set. I've tried all combinations of attributes but I can't get it to work. Am I doing something wrong ? powerpc-linux-objdump --section-headers myzimage myzimage: file format elf32-powerpc Sections: Idx Name Size VMA LMA File off Algn 0 .text 00004324 00100000 00100000 00010000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 00000460 00104330 00104330 00014330 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 000002f8 00105000 00105000 00015000 2**2 CONTENTS, ALLOC, LOAD, DATA 3 .bss 0000bbac 00106000 00106000 00016000 2**2 ALLOC 4 image 0006ccbf 00000000 00000000 00016000 2**0 CONTENTS, READONLY powerpc-linux-objcopy --set-section-flags=image=load myzimage powerpc-linux-objdump --section-headers myzimage myzimage: file format elf32-powerpc Sections: Idx Name Size VMA LMA File off Algn 0 .text 00004324 00100000 00100000 00010000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 00000460 00104330 00104330 00014330 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 000002f8 00105000 00105000 00015000 2**2 CONTENTS, ALLOC, LOAD, DATA 3 .bss 0000bbac 00106000 00106000 00016000 2**2 ALLOC 4 image 0006ccbf 00000000 00000000 00016000 2**0 CONTENTS