From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: Eli Zaretskii Cc: ezannoni@cygnus.com, dima@Chg.RU, gdb@sources.redhat.com Subject: Re: please explain some terms! Date: Mon, 21 Aug 2000 09:55:00 -0000 Message-id: <14753.24324.932539.231335@kwikemart.cygnus.com> References: <2818304729.20000819234724@Chg.RU> <200008201817.LAA03017@critters.cygnus.com> <200008210631.CAA18320@indy.delorie.com> X-SW-Source: 2000-08/msg00094.html Eli Zaretskii writes: > > Date: Sun, 20 Aug 2000 11:17:57 -0700 (PDT) > > From: Elena Zannoni > > > > > > 1) Could someone please explain the meaning of the word 'flathead', > > > found in gdbmi.texinfo? > > > > Hmm...., er,.... Flathead is a fish. This was the internal name we > > gave to the GDB MI project. :-) > > Does that mean that we should now replace all occurences of "flathead" > in gdbmi.texinfo with "GDB/MI"? Yes, that would be good. Elena >From Peter.Schauer@regent.e-technik.tu-muenchen.de Mon Aug 21 10:11:00 2000 From: "Peter.Schauer" To: benoit.millot@cstelecom.com (Benoit MILLOT) Cc: gdb@sourceware.cygnus.com Subject: Re: About GDB user-defined commands ? Date: Mon, 21 Aug 2000 10:11:00 -0000 Message-id: <200008211711.TAA15504@reisser.regent.e-technik.tu-muenchen.de> References: <39A130C9.9AE39484@cstelecom.com> X-SW-Source: 2000-08/msg00095.html Content-length: 1204 Try: define dm set var $taddr = $arg0 set var $tsize = $arg1 while $tsize != 0 if $tsize >= 10 monitor dm $taddr $tsize set var $taddr = $taddr + 10 set var $tsize = $tsize - 10 else monitor dm $taddr $tsize set var $tsize = 0 end end end > Hello, > > I want to develop a user-defined command for my own monitor > which i have already implemented into gdb with nomitor ops.. > > Can i use a new variable? (answear seems to be NO) > Can i make operation (addition, ...) with input argument (arg0 ...)? > > example: > user defined command dm : > > dm $arg0 $arg1 > > while $arg0!=3D0 > if $arg1>=3D10 > monitor dm $arg0 $arg1 > $arg1 =3D $arg1 -10 > $arg0 =3D $arg0 +10 > else > monitor dm $arg0 $arg1 > end > > I try this but it doesn't work and lines with $xxx =3D $ xxx + xxx > disappear after the first exec. > message : No symbol in cuurent context > > With line: SET $arg0 =3D $arg0 +10 > Left operand of assignement is not a Lvalue > > Any ides will be appreciated. > Thanks. > > Beno=EEt > > > -- Peter Schauer pes@regent.e-technik.tu-muenchen.de >From jtc@redback.com Mon Aug 21 11:36:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: questions about immediate_quit... Date: Mon, 21 Aug 2000 11:36:00 -0000 Message-id: <5mbsyma2cx.fsf@jtc.redback.com> X-SW-Source: 2000-08/msg00096.html Content-length: 1896 I found the following code in dcache_peek_byte(): immediate_quit++; while (done < LINE_SIZE) { int try = (*dcache->read_memory) (db->addr + done, db->data + done, LINE_SIZE - done); if (try == 0) return 0; done += try; } immediate_quit--; Even after reading the comment describing immediate_quit in utils.c, I'm still a bit puzzled. * In the above code fragment, immediate quit is incremented before the read. But it is only decremented if the read succeeds. This would appear to be an obvious bug. * From the aforementioned comment, it seems that the dcache is at too high of a level to bother with immediate_quit. If setting/reset it is necessary, it should be done in the target i/o functions. * Examination of various target bits, reveals that in most cases immediate_quit is set and reset there. However: - in some cases, instead of incrementing and decrementing immediate_quit, they are set to 1 and 0. - in other cases, the value of immediate_quit is saved in old_immediate_quit then set to 1, and finally set back to the saved value. The first case potentially loses when such calls are nested, as they are with the dcache enabled. The second works fine, but I see a value in using only one idiom throughout the gdb sources. In conclusion, I think the code touching immediate_quit in dcache.c is unnecessary, and I'll remove it in my next set of commits. I also think we should remove all assignments of 0/1 to immediate_quit and replace them with increments/decrements so that it nests properly. I think this is important even in code paths that will never nest, as any occurance in the code may be used as a template by a future contributor. I prefer good examples without gotchas... Thoughts? --jtc -- J.T. Conklin RedBack Networks >From dave@hiauly1.hia.nrc.ca Mon Aug 21 11:58:00 2000 From: "John David Anglin" To: binutils@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: VAX PC RELATIVE JMP: gas and gdb perform incorrect sign extension Date: Mon, 21 Aug 2000 11:58:00 -0000 Message-id: <200008211858.OAA02260@hiauly1.hia.nrc.ca> X-SW-Source: 2000-08/msg00097.html Content-length: 1257 In trying to build the current cvs version of gcc, I discovered an obviously long standing bug in the treatment of long pc relative branches on the vax. The following code snippet from expand_expr is incorrectly assembled by gas: tstl r9 jeql L2956 clrl -(sp) L2956 is more than 32K bytes back in the code. After linking, I see the following with adb: tstl r9 bneq 0xb4f06 jmp 0xbf867 ; wrong location 0xb4f06: clrl -(sp) The `jmp' actually goes to 0xbf867, so I believe the adb disassembly. However, when I look with gdb, I get: tstl r9 bneq 0xb4f06 jmp 0xaf867 ; location of L2956 0xb4f06: clrl -(sp) The hex value of the pc relative address is 0xa961 (0xb4f06 + 0xa961 = 0xbf867). However, gas and gdb seem to think that the vax will sign extend the word 0xa961 to the long word 0xffffa961 (0xb4f06 + 0xffffa961 = 0xaf867). This is clearly wrong. The correct offset is 0xffffa961. The error is present in expr.o, so it is not the linker which causes it. I am looking at the binutils code. Suggestions on where to look are welcome. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) >From Stephane.Carrez@worldnet.fr Mon Aug 21 13:09:00 2000 From: Stephane Carrez To: gdb@sourceware.cygnus.com Subject: New xxx_register gdb-arch function vs pseudo register Date: Mon, 21 Aug 2000 13:09:00 -0000 Message-id: <39A1A9AE.E33767A3@worldnet.fr> X-SW-Source: 2000-08/msg00098.html Content-length: 2311 Hi! I'm trying to fix the support for registers in the 68hc11 port. I have reached a problem or a limitation in GDB. I have several ways to fix that and I want to have your opinions. The 68HC11 has only 6 real hard registers but only 3 of them can really be used by GCC. Since that's too small, GCC uses several soft registers. Soft registers are in fact memory locations. Gcc, GDB-core and the GDB simulator do not know that. I would like to translate the read/write of the soft registers into a read/write of the corresponding memory location (whose address is obtained by looking at the symbol table). For this, I have two ways: 1/ Change 'gdb/regcache.c' to be able to override the 'target_fetch_registers()' and 'target_store_registers()' with a GDB multi-arch function. In that case, the 68hc11-tdep file is able to override the default, translate the fetch/store into a memory read/write or call the normal 'target_xxx_registers()'. Pros: Easy to do, less changes, homogeneous with pseudo register support Cons: New multi-arch functions. 2/ Try to use the pseudo registers framework. The problem here is that the soft registers are not aliases to other registers (nor combination of them). There are several places in GDB-core where we only take into account the NUM_REGS and not NUM_REGS+PSEUDO_REGS. For example, the frame structure must handle the saved registers but it ignores the PSEUDO_REGS. If I want to use the pseudo registers framework, it will not work because the soft registers can be saved on the stack. There are a few places like this which must be fixed. Pros: No new multi-arch function, may be fix some PSEUDO_REGS support (not sure) Cons: More complex, may change the semantics of PSEUDO_REGS I've implemented solution 1 in gdb 5.0 (but without multi-arch, just macros). What do you think? Thanks, Stephane ----------------------------------------------------------------------- Home Office E-mail: stcarrez@worldnet.fr Stephane.Carrez@sun.com WWW: http://home.worldnet.fr/stcarrez http://www.sun.com Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel 92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines France >From jtc@redback.com Mon Aug 21 16:03:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: more on immediate_quit Date: Mon, 21 Aug 2000 16:03:00 -0000 Message-id: <5mpun28bhh.fsf@jtc.redback.com> X-SW-Source: 2000-08/msg00099.html Content-length: 1174 Rummaging through the GDB sources examining the use of immediate_quit, I found another case --- this time in remote-mips.c --- where sets and resets were unbalanced. Am I safe in assuming that the below patch is what is intended? --jtc Index: remote-mips.c =================================================================== RCS file: /cvs/src/src/gdb/remote-mips.c,v retrieving revision 1.8 diff -c -r1.8 remote-mips.c *** remote-mips.c 2000/08/03 08:41:23 1.8 --- remote-mips.c 2000/08/21 22:59:17 *************** *** 609,615 **** char *p = string; int c; ! immediate_quit = 1; while (n > 0) { c = SERIAL_READCHAR (mips_desc, 2); --- 609,615 ---- char *p = string; int c; ! immediate_quit++; while (n > 0) { c = SERIAL_READCHAR (mips_desc, 2); *************** *** 618,623 **** --- 618,624 ---- { fprintf_unfiltered (gdb_stderr, "Failed to read %d characters from target (TIMEOUT)\n", n); + immediate_quit--; return 0; } *************** *** 625,630 **** --- 626,632 ---- n--; } + immediate_quit--; return 1; } -- J.T. Conklin RedBack Networks >From toddpw@windriver.com Mon Aug 21 21:21:00 2000 From: Todd Whitesel To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: questions about immediate_quit... Date: Mon, 21 Aug 2000 21:21:00 -0000 Message-id: <200008220421.VAA05220@alabama.wrs.com> References: <5mbsyma2cx.fsf@jtc.redback.com> X-SW-Source: 2000-08/msg00100.html Content-length: 361 > Thoughts? Consistent usage of global variables is a worthy cause. The decl should also have a stern comment next to it explaining how the variable is to be used, so people have no excuse when they do it wrong. (This is why fixing the bogus uses is important, so they cannot complain "but foo.c did it that way"...) -- Todd Whitesel toddpw @ windriver.com >From sashang@hotmail.com Tue Aug 22 03:07:00 2000 From: "Sashan Govender" To: gdb@sourceware.cygnus.com Subject: The debuggee's output Date: Tue, 22 Aug 2000 03:07:00 -0000 Message-id: X-SW-Source: 2000-08/msg00101.html Content-length: 412 I've been debugging gdb5 with gdb5 in an attempt to figure out how it works and, more specifically, how gdb handles output from the inferior/debuggee. I can't find the functions that take care of this. Please could some one explain how it works. Thanks Sashan ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com