From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Molenda To: gdb@sourceware.cygnus.com Subject: Re: gdb weekly snapshots Date: Wed, 12 Apr 2000 11:32:00 -0000 Message-id: <20000412113127.A7234@shell17.ba.best.com> References: <20000412112836.A3901@shell17.ba.best.com> X-SW-Source: 2000-04/msg00053.html > Jonathan wrote: > > If it's considered better just to drop the non-dejagnu snapshots, can those > > instead be made the gdb.tar.bz2/insight.tar.bz2 hard links in whatever the > > script is (those names make for easier URLs to point people at), and remove > > the old snapshots please? Andrew wrote: > At present gdb+dejagnu.tar.bz2 and insight+dejagnu.tar.bz2 snapshots are > being created. The names best reflect what is really in the archive. Well yes, but why bother being pedantic? The filenames are all eight characters longer than they need to be, when the longer name provides no additional information. If you're going to download a gdb snapshot, you're going to get dejagnu, deal with it. Why burden the filenames with extraneous characters every day? > 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. 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? Is this common enough to make all the mirror sites download a copy of this file every week? > With respect to pointing gdb.tar.bz2 -> gdb+dejagnu.tar.bz2. The mirror > sites probably won't like it. Like a separate gdb.tar.bz2 archive > (which is what I was doing) it would just increase the amount of mirror > data being shipped out each night. IMO including dejagnu in the nightly snapshots is not a big deal. Include it, don't uglify the snapshotnames with +dejagnu, and everyone is happy. J >From shebs@apple.com Wed Apr 12 12:16:00 2000 From: Stan Shebs To: Elena Zannoni Cc: gdb@sourceware.cygnus.com Subject: Re: Rombug? Date: Wed, 12 Apr 2000 12:16:00 -0000 Message-id: <38F4CB79.D82B8C9F@apple.com> References: <14580.48028.584337.869818@kwikemart.cygnus.com> X-SW-Source: 2000-04/msg00054.html Content-length: 1370 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 ezannoni@cygnus.com Wed Apr 12 12:18:00 2000 From: Elena Zannoni To: shebs@apple.com Cc: Elena Zannoni , gdb@sourceware.cygnus.com Subject: Re: Rombug? Date: Wed, 12 Apr 2000 12:18:00 -0000 Message-id: <14580.52252.842641.933519@kwikemart.cygnus.com> References: <14580.48028.584337.869818@kwikemart.cygnus.com> <38F4CB79.D82B8C9F@apple.com> X-SW-Source: 2000-04/msg00055.html Content-length: 1532 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. Aha! Excellent. > > 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. > Whoohoo! Wonderful! > Stan > Thanks Elena >From ac131313@cygnus.com Wed Apr 12 19:33:00 2000 From: Andrew Cagney To: rearnsha@arm.com Cc: gdb@sourceware.cygnus.com Subject: Re: Finding runtest Date: Wed, 12 Apr 2000 19:33:00 -0000 Message-id: <38F53184.E606882D@cygnus.com> References: <200004121100.MAA17801@cam-mail2.cambridge.arm.com> X-SW-Source: 2000-04/msg00056.html Content-length: 917 Richard Earnshaw wrote: > > gdb comes with dejagnu as part of the distribution (to ensure we use one > with the correct features). Most of the time, the make system will pick > this up automatically and use it in preference to any version that is > installed on the path. Unfortunately, this is not the case when checking > dejagnu itself. In this case, it will only work using a version that has > already been installed. > > The effect of this is that "make check" will fail when trying to check > dejagnu if dejagnu has not been previously installed on the path. > > I'm not entirely convinced that it is correct for a test program to be > testing itself, but the current behaviour is a bit inconsistent. > > Sorry no patch at the moment (I only came across this at home last night) > and haven't had chance to fix it yet. FYI, I suspect people have ``make check-gdb'' engrained in their fingers. Andrew >From ac131313@cygnus.com Wed Apr 12 19:39:00 2000 From: Andrew Cagney To: Stephane.Bihan@arccores.com Cc: gdb@sourceware.cygnus.com Subject: Re: Makefile setting Date: Wed, 12 Apr 2000 19:39:00 -0000 Message-id: <38F532C5.1D6195F8@cygnus.com> References: X-SW-Source: 2000-04/msg00057.html Content-length: 718 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? Andrew >From ac131313@cygnus.com Wed Apr 12 19:41:00 2000 From: Andrew Cagney To: gregerhaga@yahoo.com Cc: "gdb@sourceware.cygnus.com" Subject: Re: interfacing to the gdb Date: Wed, 12 Apr 2000 19:41:00 -0000 Message-id: <38F5335C.1C91220E@cygnus.com> References: <38F2A2B1.D92467@yahoo.com> X-SW-Source: 2000-04/msg00058.html Content-length: 661 Greger Haga wrote: > > Hi all, > > I was just wondering how does the gdb work with interface, I am in the > process ( a long process ) of writing a IDE for linux and would like > to incorporate the gdb in it, and would like to know how to interface > to it, any input much appreciated. Were you looking to have gdb linked into your application or as a separate program. If it is a separate program, then I'd look at the MI interface (see gdb/mi/gdbmi.texinfo). If you're looking to link gdb in then the longer term libGDB objective may be more relevant. The MI interface as a set of function calls is what is hoped libGDB will eventually provide. Andrew >From gregerhaga@yahoo.com Wed Apr 12 22:38:00 2000 From: Greger Haga To: Andrew Cagney , "gdb@sourceware.cygnus.com" Subject: Re: interfacing to the gdb Date: Wed, 12 Apr 2000 22:38:00 -0000 Message-id: <38F547D4.45D5AF2C@yahoo.com> References: <38F2A2B1.D92467@yahoo.com> <38F5335C.1C91220E@cygnus.com> X-SW-Source: 2000-04/msg00059.html Content-length: 1266 Andrew Cagney wrote: Greger Haga wrote: > > Hi all, > > I was just wondering how does the gdb work with interface, I am in the > process ( a long process ) of writing a IDE for linux and would like > to incorporate the gdb in it, and would like to know how to interface > to it, any input much appreciated. Were you looking to have gdb linked into your application or as a separate program. If it is a separate program, then I'd look at the MI interface (see gdb/mi/gdbmi.texinfo). If you're looking to link gdb in then the longer term libGDB objective may be more relevant.  The MI interface as a set of function calls is what is hoped libGDB will eventually provide. I really don't know. I need a way of interfacing to it. gdb can be run as a separate thread or process. I want to build a gui to it, be able to send commands to it and retrieve information about the debugging process, I am in a long process of writing a IDE for linux, might take years actually and started to think about how to interface to a debugger. I don't know anything about the topic so any ideas about how to do this is much appreciated. Ideally it would be integrated into the IDE that would be best. Greger           Andrew   --  Greger Haga (gregerhaga@yahoo.com) Â