Thank´s! Fernando just mailed me the path: Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.15 diff -c -w -r1.15 symtab.c *** symtab.c 2000/09/04 08:29:25 1.15 --- symtab.c 2001/01/12 19:29:21 *************** *** 754,760 **** { /* This is a mangled variable, look it up by its mangled name. */ ! return lookup_symbol (SYMBOL_NAME (msymbol), block, namespace, is_a_field_of_this, symtab); } /* There are no debug symbols for this file, or we are looking --- 754,760 ---- { /* This is a mangled variable, look it up by its mangled name. */ ! return lookup_symbol_aux (SYMBOL_NAME (msymbol), block, namespace, is_a_field_of_this, symtab); } /* There are no debug symbols for this file, or we are looking This patch was just on the gdb-patch list, right? I ´ ll give it a try tomorow, it is already 17 22:00:03 CET 2001 in HH and my eyes are like rectangels! Best regards! Jens-Christian Am Mit, 17 Jan 2001 schrieben Sie: > This is the same infinite recursion bug that we need approval for > committing. When approval is given, it will be committed, and the bug will > be fixed. > Look at gdb-patches for a recent message from Jim Ingham for the most > recent patch for this bug, and apply. It's been pissing people off for > over a month > now, but there is little that can be done, as their is no obvious bugfix > rule, as there in in gcc. > --Dan > > > On Wed, 17 Jan 2001, Jens-Christian Lache wrote: > > > Hi Fernando! Could you reproduce the problem? > > I really could need a "working" debugger! I have seen the bug described below > > not only in the toolstips, but also while trying to watch objects. > > > > > Hi everybody! > > > This is a bug report about: > > > > > > Today I encounter a problem with the gdb. I had the tooltips for variables > > > turned on. When moving the mousepointer over a field of a class, gdb startet to > > > allocote ruff amounts of mem. Only the limit of 128MB of swap could stop > > > it, it crashed and my X crashed too. I could mail you the project > > > and explain you how to reproduce this error. > > > > > > This is how to reproduce it: > > > > > > 1.) install & say "make" in the adeos dir > > > 2.) download & start it to a AT91EB01 or AT91EB40 > > > It will stop in "main" at "os.start();" > > > 3.) set a breakpoint in sched.cpp, function "Sched::start(void)", > > > third line "schedule();" > > > 4.) continue > > > 5.) move mousepointer over "state" from the line above > > > "state = Started;" Having > > > tooltips turned on, it should crash. Or try to add it to the list of > > > watch exprecions. > > > > > > My arm-elf-gdb is from 20001212. > > > > > > Regards, > > > > > > Jens-Christian > > > > > > Am Don, 11 Jan 2001 schrieben Sie: > > > > Jens-Christian Lache wrote: > > > > > > > > > > > Yes this sounds serious. But I guess I know that it is caused by a > > > > > > bug in the C++ symbol handling in GDB. It gets into an infinite loop > > > > > > when we are looking for an overloaded symbol (I don't know the > > > > > > exact circunstances). > > > > > > > > > > > > Someone has been fixing C++ things lately. Have you tried getting the > > > > > > latest insight from CVS to see if it works better for you? > > > > > Could you be a little more precise about lately? Mine is from 20001212. > > > > > > > > Jee! That sounds new enough. > > > > > > > > I guess I will have to take you on your offer to try to reproduce it. > > > > > > > > What I am going to do is to try and find someone from the GDB C++ area > > > > to look at it. I myself have not played with that code for a while and > > > > I am full of GUI stuff to do. > > > > > > > > I have seem a similar problem, so I will bug them with this one as well. > > > > Lets hope they find it fast. > > > > > > > > Maybe you should turn off your variable ballons in the meanwhile to > > > > avoid accidentaly > > > > tripping over one of those classes. There is a preference under > > > > Preferences->Source > > > > to turn them off. > > > > > > > > > > > > > Thank´s again for your great support, :-) > > > > > > > > > You're welcome. > > > > > > > > > > > > P.S.: Can you post your messages to the list? We use the archives as a > > > > knowledge base > > > > so if other people have a similar problem they can use our > > > > findings by searching > > > > the old messages. Also, sometimes there are other people who > > > > know something > > > > about the problem we are tracking down and they can jump in and > > > > help us. > > > > :-) > > > > > > > > > > > > -- > > > > Fernando Nasser > > > > Red Hat Canada Ltd. E-Mail: fnasser@redhat.com > > > > 2323 Yonge Street, Suite #300 > > > > Toronto, Ontario M4P 2C9 > > > -- > > > > > > > > > Jens-Christian Lache > > > Technische Universitaet Hamburg-Harburg > > > www.tu-harburg.de/~sejl1601 > > > Mail: > > > lache@tu-harburg.de > > > lache@ngi.de > > > Tel.: > > > +0491759610756 > > > > > > > ---------------------------------------- > > Content-Type: application/x-gzip; name="adeos.tgz" > > Content-Transfer-Encoding: base64 > > Content-Description: > > ---------------------------------------- > > > > -- > > > > > > Jens-Christian Lache > > Technische Universitaet Hamburg-Harburg > > www.tu-harburg.de/~sejl1601 > > Mail: > > lache@tu-harburg.de > > lache@ngi.de > > Tel.: > > +0491759610756 > > -- Jens-Christian Lache Technische Universitaet Hamburg-Harburg www.tu-harburg.de/~sejl1601 Mail: lache@tu-harburg.de lache@ngi.de Tel.: +0491759610756 From cgf@redhat.com Wed Jan 17 13:54:00 2001 From: Christopher Faylor To: gdb@sources.redhat.com Subject: gdb test results web page Date: Wed, 17 Jan 2001 13:54:00 -0000 Message-id: <20010117165403.A15748@redhat.com> X-SW-Source: 2001-01/msg00116.html Content-length: 727 I've been meaning to announce the existence of the gdb test results web page for some time. It is here: http://sources.redhat.com/cgi-bin/gdb.cgi This web page uses some cool software, written by Tom Tromey that helps in the categorization and comparison of test results. You can upload your own test results here by clicking on the "upload a testsuite log file" link or by sending email to gdb-testresults@sources.redhat.com. We're thinking of setting up a project on sources.redhat.com devoted to the "Terf" software which handles this web page so that people can improve it. If anyone is interested in joining this project let me know. You'll need to be fairly proficient in perl, since Terf is written in perl. cgf From chastain@cygnus.com Wed Jan 17 14:48:00 2001 From: Michael Elizabeth Chastain To: cgf@redhat.com, gdb@sources.redhat.com Subject: Re: gdb test results web page Date: Wed, 17 Jan 2001 14:48:00 -0000 Message-id: <200101172246.OAA07607@bosch.cygnus.com> X-SW-Source: 2001-01/msg00117.html Content-length: 1066 It looks promising, but I think it's not usable yet. The upload page says: UPLOAD FOR GDB Enter the file name of a test suite log file to upload: -------------------------------------------------------- | | -------------------------------------------------------- So I gave it my "gdb.log" file for 2001-01-15. Now the results page says there were 375 PASS, 7 FAIL, 0 XPASS, and 0 XFAIL for this test run. That's way too few total tests. It appears that the results page counts only results that start in column 1. That's fine for "gdb.sum" files, but it misses 90% of the results in "gdb.log" files. It looks like every entry in the current database suffers from this problem. The upload page should say more clearly whether it wants a "gdb.log" file or a "gdb.sum" file. And if it does not handle both types, then it needs to reject files of the wrong type. I have a lot more opinions but I better shut up before I get recruited! Michael Chastain "love without fear" From chienyul@yahoo.com Wed Jan 17 15:01:00 2001 From: Jeremy Lin To: gdb@sourceware.cygnus.com Subject: Using gdb with JEENI Date: Wed, 17 Jan 2001 15:01:00 -0000 Message-id: <20010117230125.9518.qmail@web2304.mail.yahoo.com> X-SW-Source: 2001-01/msg00118.html Content-length: 1519 I have a problem using JEENI with GDB 5.0 debugging. JEENI FirmwareVersion:2.0 Connected via serial port and RDI(tar rdi s=com2), I'm doing the eCos porting to our customize board based on Samsung KS32C50100 (ARM7TDMI core). Right now I'm debugging the ROM image which initialize the board. The problem is, for example, here is a sample instructions of the ROM image dump by gnu objdump: 00008060 : 8060: e59f0458 ldr r0, [pc, #458] 8064: e5800000 str r0, [r0] 00008068 : 8068: e3a00000 mov r0, #0 ; 0x0 806c: e5800040 str r0, [r0, #64] 8070: e59f144c ldr r1, [pc, #44c] 8074: e5912008 ldr r2, [r1, #8] 8078: e5802008 str r2, [r0, #8] 807c: e5912040 ldr r2, [r1, #64] 8080: e5802028 str r2, [r0, #40] 8084: ef000000 swi 0x00000000 when I set a breakpoint"b *0x8070" then "continue", it breaks normally. But after that I type "stepi" to run next instruction. This message comes out and gdb was terminated: 0 [main] arm-elf-gdb 1003 handle_exceptions: Exception: \ STATUS_ACCESS_VIOLATION 21532 [main] arm-elf-gdb 1003 stackdump: Dumping stack trace to arm-elf-gdb.exe.stack.dump Segmentation fault (core dump) This happens also when I set the 2nd breakpoint (for example, at 0x8080) and enter "continue". So I can only set one breakpoint at a time... Does any one have the same problem? __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From fnasser@cygnus.com Wed Jan 17 15:08:00 2001 From: Fernando Nasser To: Jeremy Lin Cc: gdb@sourceware.cygnus.com Subject: Re: Using gdb with JEENI Date: Wed, 17 Jan 2001 15:08:00 -0000 Message-id: <3A662600.FE7C0AEC@cygnus.com> References: <20010117230125.9518.qmail@web2304.mail.yahoo.com> X-SW-Source: 2001-01/msg00119.html Content-length: 1958 Which version of Cygwin are you using? Jeremy Lin wrote: > > I have a problem using JEENI with GDB 5.0 debugging. > JEENI FirmwareVersion:2.0 > Connected via serial port and RDI(tar rdi s=com2), > I'm doing the eCos porting to our customize board based on > Samsung KS32C50100 (ARM7TDMI core). Right now I'm debugging > the ROM image which initialize the board. The problem is, for example, > here is a sample instructions of the ROM image dump by gnu objdump: > 00008060 : > 8060: e59f0458 ldr r0, [pc, #458] > 8064: e5800000 str r0, [r0] > > 00008068 : > 8068: e3a00000 mov r0, #0 ; 0x0 > 806c: e5800040 str r0, [r0, #64] > 8070: e59f144c ldr r1, [pc, #44c] > 8074: e5912008 ldr r2, [r1, #8] > 8078: e5802008 str r2, [r0, #8] > 807c: e5912040 ldr r2, [r1, #64] > 8080: e5802028 str r2, [r0, #40] > 8084: ef000000 swi 0x00000000 > > when I set a breakpoint"b *0x8070" then "continue", it breaks > normally. But after that I type "stepi" to run next instruction. > This message comes out and gdb was terminated: > > 0 [main] arm-elf-gdb 1003 handle_exceptions: Exception: \ > STATUS_ACCESS_VIOLATION > 21532 [main] arm-elf-gdb 1003 stackdump: Dumping stack trace to > arm-elf-gdb.exe.stack.dump > Segmentation fault (core dump) > > This happens also when I set the 2nd breakpoint (for example, at 0x8080) and > enter "continue". So I can only set one breakpoint at a time... > Does any one have the same problem? > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 From ac131313@cygnus.com Wed Jan 17 16:36:00 2001 From: Andrew Cagney To: Christopher Faylor Cc: GDB Discussion Subject: Re: The ``obvious fix'' rule. Date: Wed, 17 Jan 2001 16:36:00 -0000 Message-id: <3A663A02.5E0B397D@cygnus.com> References: <3A64EDE9.74ADADAF@cygnus.com> <3A64F63A.9714D091@apple.com> <20010116204358.B10173@redhat.com> X-SW-Source: 2001-01/msg00120.html Content-length: 876 Christopher Faylor wrote: > > On Tue, Jan 16, 2001 at 05:32:42PM -0800, Stan Shebs wrote: > >Perhaps a good mental test is "will the person who hates my work > >the most be able to find fault with the change" - if so, then it's > >not obvious and needs to be posted first. :-) > > I think that this is the best criteria for an "obvious fix" that > I've ever heard. You're meant to say the ``most obvious criteria'' ... :-) A voting schema for issues was also suggested. At present we've got what I'll refer to as a consensus approach. I think this is much better than a so called vote and I think it better reflects how internet discussion really operates. A discussion, assuming people can remain focused, normally reaches the point where, appreciates understands the decision. A voting system, by its nature, typically alienates 49.9999% of the population. Andrew From tromey@redhat.com Wed Jan 17 17:46:00 2001 From: Tom Tromey To: gdb@sourceware.cygnus.com Subject: Re: gdb test results web page Date: Wed, 17 Jan 2001 17:46:00 -0000 Message-id: <87ae8psjei.fsf@creche.redhat.com> References: <200101172246.OAA07607@bosch.cygnus.com> X-SW-Source: 2001-01/msg00121.html Content-length: 886 >>>>> "Michael" == Michael Elizabeth Chastain writes: Michael> It appears that the results page counts only results that Michael> start in column 1. That's fine for "gdb.sum" files, but it Michael> misses 90% of the results in "gdb.log" files. It looks like Michael> every entry in the current database suffers from this Michael> problem. Hmm. One approach would be to fix dejagnu so that pass/fail indications always start on a new line. At least, this doesn't seem unreasonable to me. Michael> The upload page should say more clearly whether it wants a Michael> "gdb.log" file or a "gdb.sum" file. And if it does not Michael> handle both types, then it needs to reject files of the wrong Michael> type. It wants .log files. Michael> I have a lot more opinions but I better shut up before I get Michael> recruited! Indeed. Tom From ac131313@cygnus.com Wed Jan 17 17:47:00 2001 From: Andrew Cagney To: GDB Discussion Subject: Re: Pulling in purging of deprecated code? Date: Wed, 17 Jan 2001 17:47:00 -0000 Message-id: <3A664AAC.FAC65760@cygnus.com> References: <393723F4.48AA76AA@cygnus.com> X-SW-Source: 2001-01/msg00122.html Content-length: 719 Andrew Cagney wrote: > > Hello, > > With the 4.18 release, gdb started identifying obsolete code that was > going to be deleted. The 5.0 release saw the first of that code > removed. > > I'd like to suggest a slight acceleration of the process. As soon as > (or slightly after) a release has gone out the obsolete code be removed. > > This would remove the overlap that currently exists (hosts/targets may > be obsolete from the previous or next release) and also reduce the > amount of bagage GDB carries. > > Since the repository is public (and downloadable) the full history is > accessable. To close this. I got one response (agreeing with the proposal) so I'll shortly be following this through. Andrew From tromey@redhat.com Wed Jan 17 18:01:00 2001 From: Tom Tromey To: gdb@sourceware.cygnus.com Subject: Re: gdb test results web page Date: Wed, 17 Jan 2001 18:01:00 -0000 Message-id: <8766jdsj8j.fsf@creche.redhat.com> References: <200101172246.OAA07607@bosch.cygnus.com> X-SW-Source: 2001-01/msg00123.html Content-length: 401 >>>>> "Michael" == Michael Elizabeth Chastain writes: Michael> The upload page should say more clearly whether it wants a Michael> "gdb.log" file or a "gdb.sum" file. And if it does not Michael> handle both types, then it needs to reject files of the wrong Michael> type. Can you suggest how to do this? I don't see a way to tell the two kinds of files apart. Tom From ac131313@cygnus.com Wed Jan 17 18:07:00 2001 From: Andrew Cagney To: Christopher Faylor Cc: gdb@sources.redhat.com Subject: Re: gdb test results web page Date: Wed, 17 Jan 2001 18:07:00 -0000 Message-id: <3A664F5E.B67906BB@cygnus.com> References: <20010117165403.A15748@redhat.com> X-SW-Source: 2001-01/msg00124.html Content-length: 1201 A quick thanks, I'll update the web pages. Also a follow-up. This was an unofficial item on the GDB 5.1 release criteria. There had been a number of requests for a mechanism that allowed people to publish test results - this is it. When it comes to 5.1 it should be possible to just look at the test results pages and provided they are ok things can be released. (well sounds good in theory :-) Andrew Christopher Faylor wrote: > > I've been meaning to announce the existence of the gdb test results web > page for some time. It is here: > > http://sources.redhat.com/cgi-bin/gdb.cgi > > This web page uses some cool software, written by Tom Tromey that helps > in the categorization and comparison of test results. You can upload > your own test results here by clicking on the "upload a testsuite log > file" link or by sending email to gdb-testresults@sources.redhat.com. > > We're thinking of setting up a project on sources.redhat.com devoted to > the "Terf" software which handles this web page so that people can > improve it. If anyone is interested in joining this project let me > know. You'll need to be fairly proficient in perl, since Terf is written > in perl. > > cgf From chastain@cygnus.com Wed Jan 17 20:18:00 2001 From: Michael Elizabeth Chastain To: tromey@redhat.com Cc: gdb@sources.redhat.com Subject: Re: gdb test results web page Date: Wed, 17 Jan 2001 20:18:00 -0000 Message-id: <200101180421.UAA13606@train2.cygnus.com> X-SW-Source: 2001-01/msg00125.html Content-length: 1362 Tom Tromey writes: Tom> Can you suggest how to do this? I don't see a way to tell the two Tom> kinds of files apart. Here are some differences to key on for gdb.sum versus gdb.log: A gdb.log file has several '^Using' lines in the first few lines. A gdb.log file ends with the line '^runtest completed ...' You could also parse the '^# of ...' totals near the end of the file, and compare them with the count you get by grepping. If the counts do not match you could reject the file. That would protect against lots of kinds of user errors, script shortcomings, and bogus input files. Tom> Hmm. One approach would be to fix dejagnu so that pass/fail Tom> indications always start on a new line. At least, this doesn't seem Tom> unreasonable to me. Ouch, an interface problem. You are suggesting we change this: Program exited with code 01.^M (gdb) PASS: gdb.base/a2-run.exp: run "run" with no args To this: Program exited with code 01.^M (gdb) PASS: gdb.base/a2-run.exp: run "run" with no args I have two concerns. First, if we make this change in Dejagnu, it affects all tools tested with Dejagnu. And second, it means that nobody can enter any test results until this change gets made and propagated in Dejagnu. So I'm more inclined to say: leave the sender [dejagnu] alone, and change the receiver to be more liberal. Michael From ac131313@cygnus.com Wed Jan 17 20:24:00 2001 From: Andrew Cagney To: GDB Discussion Subject: Obsolete systems for GDB 5.1? Date: Wed, 17 Jan 2001 20:24:00 -0000 Message-id: <3A666F6F.90372D25@cygnus.com> X-SW-Source: 2001-01/msg00126.html Content-length: 1350 I'd like to table the following as candidates for removal from GDB. They would be marked as obsolete in GDB 5.1. The following systems were identified because they continue to use the *xdep.c* file. Rather than fix these platforms, I'd like to remove them. Eliminating *xdep.c from GDB should greatly simplify things like the move to automake (and more immediatly the long outstanding need to fix gdb/gdbserv's configury). m68030-sony-*) gdb_host=news1000 ;; m68*-isi-*) gdb_host=isi ;; m68*-sony-*) gdb_host=news ;; a29k-*-*) gdb_host=ultra3 ;; ns32k-umax-*) gdb_host=umax ;; mpw*-*-*) see mpw-config.in The following systems were identified because they they do not have a maintainer and are known to not build: i[3456]86-*-sunos*) gdb_host=sun386 ;; (This is *NOT* solaris-2) ns32k-umax-*) gdb_host=umax ;; Uses deleted function safe_strsignal(). The following systems were identified because their target does not have a maintainer *AND* I was not able to build them (FreeBSD host). The file gdb/MAINTAINERS will contain up-to-date status on this and other targets. i960 mcore mn10200 ns32k ns32k-*-mach3*) gdb_host=ns32km3 ;; ns32k-*-netbsd*) gdb_host=nbsd ;; ns32k-umax-*) gdb_host=umax ;; ns32k-utek-sysv*) gdb_host=merlin ;; tic80 v850 w65 z8k Comments. Suggestions and rejections. Andrew From cgf@redhat.com Wed Jan 17 20:28:00 2001 From: Christopher Faylor To: GDB Discussion Subject: Re: Obsolete systems for GDB 5.1? Date: Wed, 17 Jan 2001 20:28:00 -0000 Message-id: <20010117232813.A16700@redhat.com> References: <3A666F6F.90372D25@cygnus.com> X-SW-Source: 2001-01/msg00127.html Content-length: 1517 FWIW, I think that the removal of all of these makes sense. cgf On Thu, Jan 18, 2001 at 03:22:07PM +1100, Andrew Cagney wrote: >I'd like to table the following as candidates for removal from GDB. >They would be marked as obsolete in GDB 5.1. > > >The following systems were identified because they continue to use the >*xdep.c* file. > >Rather than fix these platforms, I'd like to remove them. Eliminating >*xdep.c from GDB should greatly simplify things like the move to >automake (and more immediatly the long outstanding need to fix >gdb/gdbserv's configury). > > m68030-sony-*) gdb_host=news1000 ;; > m68*-isi-*) gdb_host=isi ;; > m68*-sony-*) gdb_host=news ;; > a29k-*-*) gdb_host=ultra3 ;; > ns32k-umax-*) gdb_host=umax ;; > mpw*-*-*) see mpw-config.in > > >The following systems were identified because they they do not have a >maintainer and are known to not build: > > i[3456]86-*-sunos*) gdb_host=sun386 ;; (This is *NOT* solaris-2) > ns32k-umax-*) gdb_host=umax ;; > Uses deleted function safe_strsignal(). > > >The following systems were identified because their target does not have >a maintainer *AND* I was not able to build them (FreeBSD host). The >file gdb/MAINTAINERS will contain up-to-date status on this and other >targets. > > i960 > mcore > mn10200 > ns32k > ns32k-*-mach3*) gdb_host=ns32km3 ;; > ns32k-*-netbsd*) gdb_host=nbsd ;; > ns32k-umax-*) gdb_host=umax ;; > ns32k-utek-sysv*) gdb_host=merlin ;; > tic80 > v850 > w65 > z8k > >Comments. Suggestions and rejections. From ac131313@cygnus.com Wed Jan 17 20:54:00 2001 From: Andrew Cagney To: GDB Discussion Subject: [rfc] Remove 5.0 obsolete code Date: Wed, 17 Jan 2001 20:54:00 -0000 Message-id: <3A66767C.35FC7DC9@cygnus.com> X-SW-Source: 2001-01/msg00128.html Content-length: 8299 Hello, This follows up a discussion on the gdb@ mailing list. It removes the obsolete targets. I would draw your attention to the news file where it will now read: * OBSOLETE configurations .... Configurations that have been declared obsolete in this release have been commented out. Unless there is activity to revive these configurations, the next release of GDB will have their sources permanently REMOVED. In GDB 5.0 this note read: Configurations that have been declared obsolete will be commented out, but the code will be left in place. If there is no activity to revive these configurations before the next release of GDB, the sources will be permanently REMOVED. The old paragraph could give the impression that the removal would only occure just before the next GDB release. Given that everything is in CVS this is no longer needed. Andrew Thu Jan 18 14:03:13 2001 Andrew Cagney * configure.tgt: Remove references to convex, pyramid, altos and tahoe. * configure.host: Ditto. * MAINTAINERS: Ditto. * NEWS: Update. * tahoe-tdep.c: Delete obsolete file. * pyr-xdep.c: Ditto. * pyr-tdep.c: Ditto. * convex-tdep.c: Ditto. * convex-xdep.c: Ditto. * config/tahoe/xm-tahoe.h: Ditto. * config/tahoe/tm-tahoe.h: Ditto. * config/tahoe/tahoe.mt: Ditto. * config/tahoe/tahoe.mh: Ditto. * config/pyr/xm-pyr.h: Ditto. * config/pyr/tm-pyr.h: Ditto. * config/pyr/pyramid.mt: Ditto. * config/pyr/pyramid.mh: Ditto. * config/m68k/xm-altos.h: Ditto. * config/m68k/tm-altos.h: Ditto. * config/m68k/altos.mt: Ditto. * config/m68k/altos.mh: Ditto. * config/convex/xm-convex.h: Ditto. * config/convex/tm-convex.h: Ditto. * config/convex/convex.mt: Ditto. * config/convex/convex.mh: Ditto. * config/convex/Convex.notes: Ditto. * config/arm/xm-arm.h: Ditto. * config/arm/nm-arm.h: Ditto. * config/arm/arm.mt: Ditto. * config/arm/arm.mh: Ditto. * arm-convert.s: Ditto. * arm-xdep.c: Ditto. * altos-xdep.c: Ditto. Index: MAINTAINERS =================================================================== RCS file: /cvs/src/src/gdb/MAINTAINERS,v retrieving revision 1.62 diff -p -r1.62 MAINTAINERS *** MAINTAINERS 2001/01/16 22:45:48 1.62 --- MAINTAINERS 2001/01/18 03:36:42 *************** maintainer works with the native maintai *** 42,49 **** Jim Ingham jingham@apple.com Scott Bambrough scottb@netwinder.org - convex OBSOLETE - d10v Andrew Cagney cagney@cygnus.com d30v David Taylor taylor@cygnus.com --- 42,47 ---- *************** maintainer works with the native maintai *** 80,87 **** powerpc Kevin Buettner kevinb@cygnus.com Nick Duffek nsd@cygnus.com - pyramid OBSOLETE - romp maintenance only (?) rs6000 (see rs6000 native and ppc target) --- 78,83 ---- *************** maintainer works with the native maintai *** 89,96 **** sh Elena Zannoni ezannoni@cygnus.com sparc David Taylor taylor@cygnus.com - - tahoe OBSOLETE tic80 maintenance only (tic80-coff) v850 maintenance only (v850-elf) --- 85,90 ---- Index: NEWS =================================================================== RCS file: /cvs/src/src/gdb/NEWS,v retrieving revision 1.11 diff -p -r1.11 NEWS *** NEWS 2000/10/24 05:22:11 1.11 --- NEWS 2001/01/18 03:37:26 *************** x86 FreeBSD 3.x and 4.x i[3456]86*-fr *** 14,20 **** x86 FreeBSD before 2.2 i[3456]86*-freebsd{1,2.[01]}*, ! * Deleted configurations * Other news: --- 14,31 ---- x86 FreeBSD before 2.2 i[3456]86*-freebsd{1,2.[01]}*, ! Configurations that have been declared obsolete in this release have ! been commented out. Unless there is activity to revive these ! configurations, the next release of GDB will have their sources ! permanently REMOVED. ! ! * REMOVED configurations ! ! Altos 3068 m68*-altos-* ! Convex c1-*-*, c2-*-* ! Pyramid pyramid-*-* ! ARM RISCix arm-*-* (as host) ! Tahoe tahoe-*-* * Other news: Index: configure.host =================================================================== RCS file: /cvs/src/src/gdb/configure.host,v retrieving revision 1.10 diff -p -r1.10 configure.host *** configure.host 2000/11/26 20:04:41 1.10 --- configure.host 2001/01/18 03:37:26 *************** case "${host_cpu}" in *** 12,23 **** alpha*) gdb_host_cpu=alpha ;; arm*) gdb_host_cpu=arm ;; - # OBSOLETE c[12]) gdb_host_cpu=convex ;; hppa*) gdb_host_cpu=pa ;; i[3456]86*) gdb_host_cpu=i386 ;; m68*) gdb_host_cpu=m68k ;; m88*) gdb_host_cpu=m88k ;; - # OBSOLETE pyramid) gdb_host_cpu=pyr ;; powerpc*) gdb_host_cpu=powerpc ;; sparc64) gdb_host_cpu=sparc ;; *) gdb_host_cpu=$host_cpu ;; --- 12,21 ---- *************** alpha*-*-freebsd*) gdb_host=fbsd ;; *** 39,46 **** arm*-*-linux*) gdb_host=linux ;; arm*-*-*) gdb_host=arm ;; - # OBSOLETE c[12]-*-*) gdb_host=convex ;; - hppa*-*-bsd*) gdb_host=hppabsd ;; hppa*-*-hiux*) gdb_host=hppahpux ;; hppa*-*-hpux10.20) gdb_host=hpux1020 ;; --- 37,42 ---- *************** m680[01]0-sun-sunos3*) gdb_host=sun2os3 *** 90,96 **** m680[01]0-sun-sunos4*) gdb_host=sun2os4 ;; m68030-sony-*) gdb_host=news1000 ;; - # OBSOLETE m68*-altos-*) gdb_host=altos ;; m68*-apollo*-sysv*) gdb_host=apollo68v ;; m68*-apollo*-bsd*) gdb_host=apollo68b ;; m68*-att-*) gdb_host=3b1 ;; --- 86,91 ---- *************** powerpcle-*-solaris*) gdb_host=solaris ; *** 140,149 **** powerpc-*-linux*) gdb_host=linux ;; powerpc-*-netbsd*) gdb_host=nbsd ;; - # OBSOLETE pn-*-*) gdb_host=pn ;; - - # OBSOLETE pyramid-*-*) gdb_host=pyramid ;; - romp-*-*) gdb_host=rtbsd ;; rs6000-*-lynxos*) gdb_host=rs6000lynx ;; --- 135,140 ---- *************** sparc64-*-*) gdb_host=sun4sol2 ;; *** 163,170 **** strongarm-*-*) gdb_host=arm ;; xscale-*-*) gdb_host=arm ;; - - # OBSOLETE tahoe-*-*) gdb_host=tahoe ;; vax-*-bsd*) gdb_host=vaxbsd ;; vax-*-ultrix2*) gdb_host=vaxult2 ;; --- 154,159 ---- Index: configure.tgt =================================================================== RCS file: /cvs/src/src/gdb/configure.tgt,v retrieving revision 1.16 diff -p -r1.16 configure.tgt *** configure.tgt 2000/12/14 20:15:45 1.16 --- configure.tgt 2001/01/18 03:37:26 *************** case "${target_cpu}" in *** 14,20 **** alpha*) gdb_target_cpu=alpha ;; arm*) gdb_target_cpu=arm ;; - # OBSOLETE c[12]) gdb_target_cpu=convex ;; hppa*) gdb_target_cpu=pa ;; i[3456]86*) gdb_target_cpu=i386 ;; m68hc11*|m6811*) gdb_target_cpu=m68hc11 ;; --- 14,19 ---- *************** m68*) gdb_target_cpu=m68k ;; *** 22,28 **** m88*) gdb_target_cpu=m88k ;; mips*) gdb_target_cpu=mips ;; powerpc*) gdb_target_cpu=powerpc ;; - # OBSOLETE pyramid) gdb_target_cpu=pyr ;; sparc*) gdb_target_cpu=sparc ;; thumb*) gdb_target_cpu=arm ;; strongarm*) gdb_target_cpu=arm ;; --- 21,26 ---- *************** arm*-*-* | thumb*-*-* | strongarm*-*-*) *** 63,70 **** xscale-*-*) gdb_target=embed configdirs="$configdirs rdi-share" ;; - # OBSOLETE c1-*-*) gdb_target=convex ;; - # OBSOLETE c2-*-*) gdb_target=convex ;; d10v-*-*) gdb_target=d10v ;; d30v-*-*) gdb_target=d30v ;; --- 61,66 ---- *************** m68*-apollo*-bsd*) gdb_target=apollo68b *** 149,155 **** m68*-bull-sysv*) gdb_target=dpx2 ;; m68*-hp-bsd*) gdb_target=hp300bsd ;; m68*-hp-hpux*) gdb_target=hp300hpux ;; - # OBSOLETE m68*-altos-*) gdb_target=altos ;; m68*-att-*) gdb_target=3b1 ;; m68*-cisco*-*) gdb_target=cisco ;; m68*-ericsson-*) gdb_target=es1800 ;; --- 145,150 ---- *************** powerpcle-*-eabi* | powerpcle-*-sysv* | *** 255,262 **** powerpc-*-linux*) gdb_target=linux ;; powerpc-*-vxworks*) gdb_target=vxworks ;; - # OBSOLETE pyramid-*-*) gdb_target=pyramid ;; - rs6000-*-lynxos*) gdb_target=rs6000lynx configdirs="${configdirs} gdbserver" ;; rs6000-*-aix4*) gdb_target=aix4 ;; --- 250,255 ---- *************** sparc86x-*-*) gdb_target=sparclite ;; *** 288,295 **** # deleted though presumably it should be eventually. #sparc64-*-solaris2*) gdb_target=sp64sol2 ;; sparc64-*-*) gdb_target=sp64 ;; - - # OBSOLETE tahoe-*-*) gdb_target=tahoe ;; tic80-*-*) gdb_target=tic80 configdirs="${configdirs} gdbserver" ;; --- 281,286 ---- From ac131313@cygnus.com Thu Jan 18 06:43:00 2001 From: Andrew Cagney To: Will Cohen Cc: gdb@sourceware.cygnus.com Subject: Re: Handling of mips disassembly by gdb Date: Thu, 18 Jan 2001 06:43:00 -0000 Message-id: <3A67009D.4AEBD43B@cygnus.com> References: <39F0C5E9.CC6A0CF9@redhat.com> X-SW-Source: 2001-01/msg00129.html Content-length: 970 Will Cohen wrote: > > The disassembly performed by the function _print_insn_mips in > opcode/mips-dis.c is dependent on the mach field of the struct info > passed to the function. Unfortunately the mach field is alway set to > zero because TM_PRINT_INSN_MACH is defined to be 0 in > gdb/config/mips/tm-mip.h. Is there a reason that this must be set to > zero? Wouldn't it be more appropriate to set it to > ((TARGET_PRINT_INSN_INFO)->mach)? Changing this line allows the > disassembler to generate model specific instructions. > > Should I generate a patch to fix this and submit it to binutils? Or is > there a reason this define was set to zero? You may want to check exactly how objdump handles things like MIPS16 vs MIPS-1-IV code and ARM vs THUMB. By default, GDB just calls the dissassembler and hopes that it knows what the architecture is for the current memory range. For your case, does a simple objdump dissassemble code the way you expect? Andrew From tromey@redhat.com Thu Jan 18 13:40:00 2001 From: Tom Tromey To: Michael Elizabeth Chastain Cc: gdb@sources.redhat.com Subject: Re: gdb test results web page Date: Thu, 18 Jan 2001 13:40:00 -0000 Message-id: <87g0igpv17.fsf@creche.redhat.com> References: <200101180421.UAA13606@train2.cygnus.com> X-SW-Source: 2001-01/msg00130.html Content-length: 901 >>>>> "Michael" == Michael Elizabeth Chastain writes: Michael> I have two concerns. First, if we make this change in Michael> Dejagnu, it affects all tools tested with Dejagnu. And Michael> second, it means that nobody can enter any test results until Michael> this change gets made and propagated in Dejagnu. I think the current behavior is just a dejagnu bug. I doubt anybody relies on "PASS" or "FAIL" not appearing at the start of a line. And I doubt it was ever intended to work the way it does -- dejagnu wasn't that carefully built. Second, I don't think propagation is a big problem. I thought everybody was supposed to use the dejagnu in the src repository. If we were dealing with non-free software I would agree with you. But I think with free software we can afford to have a higher standard -- fix the bug where it lies, not work around it elsewhere. Tom From jtc@redback.com Thu Jan 18 13:53:00 2001 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: GDB Discussion Subject: Re: Obsolete systems for GDB 5.1? Date: Thu, 18 Jan 2001 13:53:00 -0000 Message-id: <5mwvbs4ruu.fsf@jtc.redback.com> References: <3A666F6F.90372D25@cygnus.com> X-SW-Source: 2001-01/msg00131.html Content-length: 804 >>>>> "Andrew" == Andrew Cagney writes: Andrew> I'd like to table the following as candidates for removal from Andrew> GDB. They would be marked as obsolete in GDB 5.1. The Andrew> following systems were identified because their target does Andrew> not have a maintainer *AND* I was not able to build them Andrew> (FreeBSD host). The file gdb/MAINTAINERS will contain Andrew> up-to-date status on this and other targets. Andrew> Andrew> ns32k Andrew> ns32k-*-mach3*) gdb_host=ns32km3 ;; Andrew> ns32k-*-netbsd*) gdb_host=nbsd ;; Andrew> ns32k-umax-*) gdb_host=umax ;; Andrew> ns32k-utek-sysv*) gdb_host=merlin ;; Andrew> Andrew> Comments. Suggestions and rejections. I'll be fixing the ns32k-*-netbsd* before 5.1. --jtc -- J.T. Conklin RedBack Networks From chienyul@yahoo.com Thu Jan 18 14:18:00 2001 From: Jeremy Lin To: gdb@sourceware.cygnus.com Subject: Re: Using gdb with JEENI Date: Thu, 18 Jan 2001 14:18:00 -0000 Message-id: <20010118181844.15687.qmail@web2302.mail.yahoo.com> X-SW-Source: 2001-01/msg00132.html Content-length: 2327 It is cygwin 1.1, I installed in in August 2000. Thanks! Jeremy Lin --- Fernando Nasser wrote: > Which version of Cygwin are you using? > > Jeremy Lin wrote: > > > > I have a problem using JEENI with GDB 5.0 debugging. > > JEENI FirmwareVersion:2.0 > > Connected via serial port and RDI(tar rdi s=com2), > > I'm doing the eCos porting to our customize board based on > > Samsung KS32C50100 (ARM7TDMI core). Right now I'm debugging > > the ROM image which initialize the board. The problem is, for example, > > here is a sample instructions of the ROM image dump by gnu objdump: > > 00008060 : > > 8060: e59f0458 ldr r0, [pc, #458] > > 8064: e5800000 str r0, [r0] > > > > 00008068 : > > 8068: e3a00000 mov r0, #0 ; 0x0 > > 806c: e5800040 str r0, [r0, #64] > > 8070: e59f144c ldr r1, [pc, #44c] > > 8074: e5912008 ldr r2, [r1, #8] > > 8078: e5802008 str r2, [r0, #8] > > 807c: e5912040 ldr r2, [r1, #64] > > 8080: e5802028 str r2, [r0, #40] > > 8084: ef000000 swi 0x00000000 > > > > when I set a breakpoint"b *0x8070" then "continue", it breaks > > normally. But after that I type "stepi" to run next instruction. > > This message comes out and gdb was terminated: > > > > 0 [main] arm-elf-gdb 1003 handle_exceptions: Exception: \ > > STATUS_ACCESS_VIOLATION > > 21532 [main] arm-elf-gdb 1003 stackdump: Dumping stack trace to > > arm-elf-gdb.exe.stack.dump > > Segmentation fault (core dump) > > > > This happens also when I set the 2nd breakpoint (for example, at 0x8080) > and > > enter "continue". So I can only set one breakpoint at a time... > > Does any one have the same problem? > > > > __________________________________________________ > > Do You Yahoo!? > > Get email at your own domain with Yahoo! Mail. > > http://personal.mail.yahoo.com/ > > -- > Fernando Nasser > Red Hat - Toronto E-Mail: fnasser@redhat.com > 2323 Yonge Street, Suite #300 > Toronto, Ontario M4P 2C9 __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From cgf@redhat.com Thu Jan 18 14:36:00 2001 From: Christopher Faylor To: gdb@sources.redhat.com Subject: Re: gdb test results web page Date: Thu, 18 Jan 2001 14:36:00 -0000 Message-id: <20010118173615.A1274@redhat.com> References: <200101180421.UAA13606@train2.cygnus.com> <87g0igpv17.fsf@creche.redhat.com> X-SW-Source: 2001-01/msg00133.html Content-length: 873 On Thu, Jan 18, 2001 at 11:36:20AM -0700, Tom Tromey wrote: >>>>>> "Michael" == Michael Elizabeth Chastain writes: > >Michael> I have two concerns. First, if we make this change in >Michael> Dejagnu, it affects all tools tested with Dejagnu. And >Michael> second, it means that nobody can enter any test results until >Michael> this change gets made and propagated in Dejagnu. > >I think the current behavior is just a dejagnu bug. I doubt anybody >relies on "PASS" or "FAIL" not appearing at the start of a line. And >I doubt it was ever intended to work the way it does -- dejagnu wasn't >that carefully built. It is not that hard to modify terf to find the PASS/FAIL/XFAIL in other places than at the beginning of the line. I've just checked in a change to do this. Do you think this is a bad idea, Tom? If so, I'll revert the change. cgf From jlarmour@redhat.com Thu Jan 18 14:40:00 2001 From: jlarmour@redhat.com (Jonathan Larmour) To: ac131313@cygnus.com Cc: gdb@sources.redhat.com Subject: Re: Obsolete systems for GDB 5.1? Date: Thu, 18 Jan 2001 14:40:00 -0000 Message-id: <200101181826.f0IIQZs16097@murgh.cambridge.redhat.com> References: <3A666F6F.90372D25@cygnus.com> X-SW-Source: 2001-01/msg00135.html Content-length: 567 In article < 3A666F6F.90372D25@cygnus.com > you write: >I'd like to table the following as candidates for removal from GDB. >They would be marked as obsolete in GDB 5.1. [snip] > v850 It may not build right now, but we support this within Red Hat. Just because there is no individual capable of being the maintainer doesn't mean that no-one will be fixing it: the entity known as Red Hat as a whole will. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine From jtc@redback.com Thu Jan 18 14:40:00 2001 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: GDB Discussion Subject: Re: Obsolete systems for GDB 5.1? Date: Thu, 18 Jan 2001 14:40:00 -0000 Message-id: <5mwvbs32nv.fsf@jtc.redback.com> References: <3A666F6F.90372D25@cygnus.com> X-SW-Source: 2001-01/msg00134.html Content-length: 765 >>>>> "Andrew" == Andrew Cagney writes: Andrew> ns32k Andrew> ns32k-*-mach3*) gdb_host=ns32km3 ;; Andrew> ns32k-*-netbsd*) gdb_host=nbsd ;; Andrew> ns32k-umax-*) gdb_host=umax ;; Andrew> ns32k-utek-sysv*) gdb_host=merlin ;; Andrew> Andrew> Comments. Suggestions and rejections. It seems that much of the ns32k build lossage was caused by a change made to tm-umax.h between the 19990504 and 19990525 snapshots (I can not narrow it down further, this was before the GDB repository on sourceware was made the master repository, perhaps someone at cygnus can track it down) where the FRAME_FIND_SAVED_REGS macro was removed. There was no ChangeLog entry cooresponding to this change. --jtc -- J.T. Conklin RedBack Networks From tromey@redhat.com Thu Jan 18 15:16:00 2001 From: Tom Tromey To: gdb@sourceware.cygnus.com Subject: Re: gdb test results web page Date: Thu, 18 Jan 2001 15:16:00 -0000 Message-id: <87lms8l9gb.fsf@creche.redhat.com> References: <200101180421.UAA13606@train2.cygnus.com> <87g0igpv17.fsf@creche.redhat.com> <20010118173615.A1274@redhat.com> X-SW-Source: 2001-01/msg00136.html Content-length: 286 >>>>> "Chris" == Christopher Faylor writes: Chris> Do you think this is a bad idea, Tom? If so, I'll revert the Chris> change. I doubt it is actively bad. I've just reached my limit of catering to dejagnu brokenness. Perhaps I'll send a dejagnu patch. Tom From miocartu@hotmail.com Thu Jan 18 15:37:00 2001 From: "Bapsa" To: "gdb@sourceware.cygnus.com" Subject: Imprimi sin culpas!! Date: Thu, 18 Jan 2001 15:37:00 -0000 Message-id: <08dc23236231211MAIL2@mail2.arnet.com.ar> X-SW-Source: 2001-01/msg00137.html Content-length: 859 Title: Untitled Document ATENCION, NO TIRES TUS CARTUCHOS      Hola, no queremos sacarte tu tiempo, si tenés cartuchos de impresora, hace click en www.loscartuchos.com o llamanos al 4828-0174 , los recuperamos en 24 horas y cuestan $15 color o negro para cualquier impresora. No importa donde vivas, tienen garantía, salen probados y quedan como nuevos . AHORA AHORRAS, IMPRIMI SIN CULPAS BAPSA Â