From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: jason-swarelist@molenda.com Cc: gdb@sourceware.cygnus.com Subject: Re: gdb weekly snapshots Date: Thu, 13 Apr 2000 02:35:00 -0000 Message-id: <200004130934.FAA06539@indy.delorie.com> References: <20000412112836.A3901@shell17.ba.best.com> <20000412113127.A7234@shell17.ba.best.com> X-SW-Source: 2000-04/msg00065.html > Date: Wed, 12 Apr 2000 11:31:28 -0700 > From: Jason Molenda > > Andrew wrote: > > > Also of interest is the weekly *-CVS-* file. It contains a full CVS > > checkout (although right now it is a checkout of the GDB-5.0 branch). > > Is this actually useful? If someone does > > cvs -d ... -z9 co gdb > > They'll get a cvs checkout of GDB (or add the branchname to get > the branch) just as fast as if they'd grabbed the snapshot. Not everyone has CVS installed on every development machine they use. I, for one, only have CVS on one machine, which is not my main development platform. > I > guess there is less load on sourceware if they download a > pre-checked-out tarfile, but how many people actually do this in > a week? I use snapshots and *diff.bz2 files almost exclusively. I almost never do "cvs up", for some valid reasons which I prefer not to go into. >From dan@cgsoftware.com Thu Apr 13 08:19:00 2000 From: dan@cgsoftware.com (Daniel Berlin) To: gdb@sourceware.cygnus.com Subject: Bcache'ing as a speedup Date: Thu, 13 Apr 2000 08:19:00 -0000 Message-id: X-SW-Source: 2000-04/msg00066.html Content-length: 434 Ya know, i was thinking (yes, dangerous, i know). If we bcache every symbol/psymbol/minsym name, and i mean literally every single one, couldn't we just do simple pointer compares (IE a==b) rather than strcmp (assuming we weren't doing a strcmp_Iw, which obviously would still need to be done), since if they were the same string, they would *have* to be pointing to the same memory? Wouldn't this be a pretty large speed win? --Dan >From jlarmour@redhat.co.uk Thu Apr 13 10:47:00 2000 From: jlarmour@redhat.co.uk (Jonathan Larmour) To: csim@iris.snu.ac.kr Cc: gdb@sourceware.cygnus.com Subject: Re: remote debugging stub for ep7212 processor Date: Thu, 13 Apr 2000 10:47:00 -0000 Message-id: <200004131747.SAA09892@murgh.cygnus.co.uk> References: <002d01bfa04a$e884bae0$d9792e93@snu.ac.kr> X-SW-Source: 2000-04/msg00067.html Content-length: 541 In article < 002d01bfa04a$e884bae0$d9792e93@snu.ac.kr > you write: >Hi. >I'm looking for GDB stub for remote debugging of ep7212 processor. >Is there anyone who have experienced about that? >If any, could you tell me where can I get it? >If not, how can I make it myself? eCos ( http://sourceware.cygnus.com/ecos/ ) can be configured to build a stub for the EP7212 eval board. Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault >From ezannoni@cygnus.com Thu Apr 13 11:49:00 2000 From: Elena Zannoni To: shebs@apple.com Cc: Elena Zannoni , gdb@sourceware.cygnus.com Subject: Re: Rombug? Date: Thu, 13 Apr 2000 11:49:00 -0000 Message-id: <14582.5795.222477.937414@kwikemart.cygnus.com> References: <14580.48028.584337.869818@kwikemart.cygnus.com> <38F4CB79.D82B8C9F@apple.com> X-SW-Source: 2000-04/msg00068.html Content-length: 1696 I forgot to mention that another rombug hack is present in symbol_file_command(). Same story, it gets the .text address from the target side. Can I get rid of that too? It would simplify the code quite a lot. Elena Stan Shebs writes: > Elena Zannoni wrote: > > > > While cleaning up the syntax for add-symbol-file, I saw that that > > command has a special syntax just for the rombug case. For rombug, one > > doesn't need to specify the address of the .text section to load the > > file at. For all the other cases, such address must instead be specified as > > argument to the command. Needless to say, this little variation > > complicates things quite a bit. > > > > When is rombug used and what exactly is it? There is a brief mention of > > it in the gdb manual, but not enough for me to understand much. > > Is it still in use? > > Rombug is the boot monitor for Microware's OS-9 / OS-9000 (yes, these are > the guys that are suing Apple over having a version 9 of MacOS, believe > it or not), so its role is similar to that of CygMon in eCos. > remote-os9k.c is just another cheesy monitor interface, and probably > hasn't been used in a long time, so I don't anybody will notice if it > crumbles a little more. From surfing around Microware's web site > (www.microware.com), it looks like they recommend their own proprietary > debug protocol anyway. > > I'd recommend leaving out the special rombug hack, but putting extra > notes in the sources and ChangeLog, so that if someone goes looking for > it in the future, they won't wonder if they were hallucinating when they > remembered some sort of rombug support in add-symbol-file. > > Stan > >From jlarmour@redhat.co.uk Thu Apr 13 14:47:00 2000 From: Jonathan Larmour To: insight@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Insight remote output doesn't output to console window immediately Date: Thu, 13 Apr 2000 14:47:00 -0000 Message-id: <38F6404E.5959A4E0@redhat.co.uk> X-SW-Source: 2000-04/msg00069.html Content-length: 1773 [ Sent to gdb and insight lists since ] I've found a problem in insight that is surprisingly old - I can't imagine how it's lived so long actually: output from a remote target doesn't get sent to the console window as it arrives. Instead it is buffered up. I believe the problem is because of Cagney's change to remote.c on July 2nd 1999 which changed remote_console_output to operate on the gdb_stdtarg stream rather than gdb_stdout. But, in main.c, gdb_stdtarg is #defined to gdb_stderr. Which means that it matches the following code in gdbtk/generic/gdbtk-hooks.c in gdbtk_fputs(): if (result_ptr != NULL) { if (result_ptr->flags & GDBTK_TO_RESULT) ... else if (stream == gdb_stderr || result_ptr->flags & GDBTK_ERROR_ONLY) { if (result_ptr->flags & GDBTK_ERROR_STARTED) Tcl_AppendToObj (result_ptr->obj_ptr, (char *) ptr, -1); else { Tcl_SetStringObj (result_ptr->obj_ptr, (char *) ptr, -1); result_ptr->flags |= GDBTK_ERROR_STARTED; } i.e. it is appended to result_ptr, rather than calling gdbtk_tcl_fputs to display it in the console window. The only thing I'm wondering about is the fix. We could #define gdb_stdtarg to gdb_stdout instead. Or we could add a hook with set_ui_file_flush() so that the "gdb_flush (gdb_stdtarg);" at the end of remote_console_output() would do the right thing. I simply don't know which is the more correct fix before I implement it, although I suspect the latter. Let me know - I'd like to sort this out soon because it affects Insight 5 (?) as well. Ta, Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault >From kettenis@wins.uva.nl Thu Apr 13 15:12:00 2000 From: Mark Kettenis To: ac131313@cygnus.com Cc: gdb@sourceware.cygnus.com, msnyder@cygnus.com Subject: Re: Disabling lin-thread.c module Date: Thu, 13 Apr 2000 15:12:00 -0000 Message-id: <200004132146.e3DLk2013680@delius.kettenis.local> References: <200004101237.OAA29849@landau.wins.uva.nl> <38F56FDE.A18A9165@cygnus.com> X-SW-Source: 2000-04/msg00070.html Content-length: 1805 Date: Thu, 13 Apr 2000 16:57:34 +1000 From: Andrew Cagney GDB 5.0 is all about getting new features and being able to boast about them. GDB 5.0 is also all about kick starting the public CVS repository and getting real community development. I suspect that people in mission critical situations will think twice about jumping on a new radical GDB 5.0 when: o they see an even/zero sub-version (always a bad sign :-) o they know a 5.1 is coming soon With respect to thread_db, my understanding is that it is no less functional (1) then the old GDB-4.18 while at the same time, definitely being better architecturally designed (true?). No matter how much testing effort is put in, it is always going to take a release before it becomes stable. Enable it now, and 5.1 should be ok. Enable it in 5.1 and 5.2 (a year from now?) is likely stable :-/ Since GDB 4.18 didn't support threads on Linux GDB 5.0 will certainly be `no less functional' :-). Unfortunately people will compare 5.0 to HJ's "improved" 4.17 based version. I suspect that that version still does handle threads somewhat better than the current code in 5.0. But I guess our only chance to improve things is getting the code out, and hope that people will dump HJ's version when they discover all the nifty new features in GDB 5.0, and see that we're actually fixing the bugs thet reported :-). Anyhow, the strongest argument for shipping the libthread_db code is that this will put an end to the practice of fixing GDB over and over again when the internals of the LinuxThreads library are changed. The decision is between the thread and Linux maintainers. The thread maintainer said ya, so linux maintainers? That's a `ja' from me to :-). Mark >From ac131313@cygnus.com Thu Apr 13 16:53:00 2000 From: Andrew Cagney To: Jonathan Larmour Cc: insight@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Insight remote output doesn't output to console window immediately Date: Thu, 13 Apr 2000 16:53:00 -0000 Message-id: <38F65D4D.8B390EFA@cygnus.com> References: <38F6404E.5959A4E0@redhat.co.uk> X-SW-Source: 2000-04/msg00071.html Content-length: 2316 Jonathan Larmour wrote: > > [ Sent to gdb and insight lists since ] > > I've found a problem in insight that is surprisingly old - I can't imagine > how it's lived so long actually: output from a remote target doesn't get > sent to the console window as it arrives. Instead it is buffered up. > > I believe the problem is because of Cagney's change to remote.c on July 2nd > 1999 which changed remote_console_output to operate on the gdb_stdtarg > stream rather than gdb_stdout. But, in main.c, gdb_stdtarg is #defined to > gdb_stderr. Which means that it matches the following code in > gdbtk/generic/gdbtk-hooks.c in gdbtk_fputs(): Yes, most likely :-( > if (result_ptr != NULL) > { > if (result_ptr->flags & GDBTK_TO_RESULT) > ... > else if (stream == gdb_stderr || result_ptr->flags & > GDBTK_ERROR_ONLY) > { > if (result_ptr->flags & GDBTK_ERROR_STARTED) > Tcl_AppendToObj (result_ptr->obj_ptr, (char *) ptr, -1); > else > { > Tcl_SetStringObj (result_ptr->obj_ptr, (char *) ptr, -1); > result_ptr->flags |= GDBTK_ERROR_STARTED; > } > > i.e. it is appended to result_ptr, rather than calling gdbtk_tcl_fputs to > display it in the console window. > > The only thing I'm wondering about is the fix. We could #define gdb_stdtarg > to gdb_stdout instead. Or we could add a hook with set_ui_file_flush() so > that the "gdb_flush (gdb_stdtarg);" at the end of remote_console_output() > would do the right thing. I simply don't know which is the more correct fix > before I implement it, although I suspect the latter. There is no need for another hook. Even the existing hooks (gdbtk_fputs() and gdbtk_flush()) can, in theory, deleted. To see how it should work, check the MI (mi/mi-main.c) - it maintains a separate stream. (BTW, sending the output gdb_stdout is wrong in CLI mode. gdb_stdout is paged. Having ``more ....'' appear part way through target output in CLI mode is only a little less frustrating than delayed output in GUI mode :-) As for a quick hack? My first guess is to, when the GUI is enabled (ie not CLI mode), re-route gdb_stdtarg to gdb_stdout. That might be suitable for the branch. However, the trunk, needs to start taking advantage of ``struct ui_out''. Andrew >From jingham@cygnus.com Thu Apr 13 16:56:00 2000 From: James Ingham To: Andrew Cagney Cc: Jonathan Larmour , insight@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Insight remote output doesn't output to console window immediately Date: Thu, 13 Apr 2000 16:56:00 -0000 Message-id: <14582.24424.847207.786618@leda.cygnus.com> References: <38F6404E.5959A4E0@redhat.co.uk> <38F65D4D.8B390EFA@cygnus.com> X-SW-Source: 2000-04/msg00072.html Content-length: 480 Andrew, > > > As for a quick hack? > > My first guess is to, when the GUI is enabled (ie not CLI mode), > re-route gdb_stdtarg to gdb_stdout. That might be suitable for the > branch. However, the trunk, needs to start taking advantage of ``struct > ui_out''. > Yup, this is pretty high on the to-do list, pretty close after rewriting the source window code so it is maintainable, and figuring out how to handle hangs in target communication more gracefully. Jim >From ac131313@cygnus.com Thu Apr 13 19:41:00 2000 From: Andrew Cagney To: Stephane.Bihan@arccores.com Cc: gdb@sourceware.cygnus.com Subject: Re: multi-arch (was Re: Makefile setting) Date: Thu, 13 Apr 2000 19:41:00 -0000 Message-id: <38F684CE.C1C8AD3@cygnus.com> References: X-SW-Source: 2000-04/msg00073.html Content-length: 2433 Stephane.Bihan@arccores.com wrote: > > Stephane.Bihan@arccores.com wrote: > > > > > > > > the ARC supported implementation of gdb we are trying to achieve is > > > > > "extensible". > > > > > The register description is minimal in the sense that only the > basecase > > > > > registers are described in REGISTER_NAMES. > > > > > This description is updated (more registers are added) when we connect > to > > > the > > > > > simulator. > > > > > > > > Hmm, I'd suggest investigating the multi-arch framework. It better > > > > handles things like an architecture suddenly deciding it needs to be > > > > changed. A target can also forced multi-arch to re-select its > > > > architecture if needed. > > > > > > > > http://sourceware.cygnus.com/gdb/papers/multi-arch/ > > > > > > > > For the register extensions, are they known by arcExtMap or are they > > > > obtained from the target? > > > > > > > They are extracted from the object file. > > > > Good, multi-arch should definitly help. When a new object file is > > presented to GDB the multi-arch framework is asked to identify it and > > create an architecture for it. arc-tdep.c can be set up to identify > > that information and set up things like the REGISTER_NAME > > (REGISTER_NAMES is being given the boot :-) for the relevant target. > > > > Just a few speed bumps to climb over before it starts to help. > > That's a really good idea this multi-arch proposal! A better description is probably a road map. MIPS, IA-64, D10V already make use of the basic framework Several others (mn10300, SPARC, i386) are all well down that same path. The rs6000 and SH are both on the hit list. > Just a shame I didn't read the paper before. > I've implemented the REGISTER_NAMES initialisation in another way now. > And I haven't got too much time to change it before sending you the sources of > our ARC port. To be clear and up front. If someone contributes support for some new architecture then that new architecture will need to use the multi-arch framework (see IA-64). If someone contributes changes/fixes to an old target/architecture (which would be your case I think) then those changes will need to be in line with the general direction that multi-arch is taking. Post the changes and lets see where it stands. It hopefully just involves simple things like replacing your #define REGISTER_NAMES with #define REGISTER_NAME(i) (arc_register_name (i)). Andrew >From Stephane.Bihan@arccores.com Fri Apr 14 02:24:00 2000 From: Stephane.Bihan@arccores.com To: Andrew Cagney Cc: gdb@sourceware.cygnus.com, Stephane.Bihan@arccores.com Subject: Re: multi-arch (was Re: Makefile setting) Date: Fri, 14 Apr 2000 02:24:00 -0000 Message-id: X-SW-Source: 2000-04/msg00074.html Content-length: 1611 > > > > That's a really good idea this multi-arch proposal! > > A better description is probably a road map. MIPS, IA-64, D10V already > make use of the basic framework Several others (mn10300, SPARC, i386) > are all well down that same path. The rs6000 and SH are both on the hit > list. I can't see any multi-arch implementation in the current gdb-4.18 sources. I can't see either any IA64 port. > > > Just a shame I didn't read the paper before. > > I've implemented the REGISTER_NAMES initialisation in another way now. > > And I haven't got too much time to change it before sending you the sources of > > our ARC port. > > To be clear and up front. > > If someone contributes support for some new architecture then that new > architecture will need to use the multi-arch framework (see IA-64). > > If someone contributes changes/fixes to an old target/architecture > (which would be your case I think) then those changes will need to be in > line with the general direction that multi-arch is taking. Post the > changes and lets see where it stands. There is quite a few changes actually. there is the simulator developped by Chameleon Inc, a remote-arc target (which is a copy of remote.c a bit extended for our hardware target), some others files to read the extensions and build a map of them, the arc-disassembler totally changed to take these extensions into account. > It hopefully just involves simple > things like replacing your #define REGISTER_NAMES with #define > REGISTER_NAME(i) (arc_register_name (i)). As soon as I will find a roadmap, I'll do these changes. Cheers, Stephane.