From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: Moving Linux-specific stuff out of i386-tdep.c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C7AE49.3E364033@cygnus.com> References: <200003082121.e28LLRu05681@delius.kettenis.local> <1000308222742.ZM8876@ocotillo.lan> <200003091349.IAA19958@indy.delorie.com> X-SW-Source: 2000-q1/msg00645.html Eli Zaretskii wrote: > > > The 8.3 uniqueness rule definitly still applies. > > Should I post a list of files which violate that rule? Sorry, applies when it matters - any files you need. :-) Andrew >From hjl@lucon.org Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: Jim Kingdon Cc: gdb@sourceware.cygnus.com Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000207093417.A10546@lucon.org> References: <389ECBAF.66013B07@cygnus.com> <200002071626.RAA18391@landau.wins.uva.nl> X-SW-Source: 2000-q1/msg00126.html Content-length: 1540 On Mon, Feb 07, 2000 at 09:08:51AM -0800, Jim Kingdon wrote: > > * Support for unloading of shared libraries. The current code-base > > doesn't really support this. HJ Lu forwarded some patches that hack > > around this, but I don't think they are acceptable. They introduce > > two more (uneccessary) hooks. Personally I don't fixing this for > > GDB 5.0 terribly important. There isn't that many code out there, that > > explicitly unloads shared libs. > > As far as I know there is more out there than you might realize. A > modern application like mozilla uses dlopen() a lot (feel free to > flame about whether this tendency is a fad or really useful but that > isn't the point). For example see > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=5130 > > > > I think having an "x86 linux native" port with working threads support > > in GDB 5.0 is very important. > > Have you tried GDB from CVS in the last 6 months or so? I'm not aware > of any known bugs and Red Hat Linux has been shipping with the code > which is in CVS for a while (I can offer details if needed). > gdb 4.17.0.14 has one patch from Sam to deal with shared libraries. People who want to debug shared libraries may not want to use gdb in CVS. As you have mentioned above, it is not that unusual nowdays. We have patches and they seem to work. We can make gdb 5.0 to work with shared libraries. If we continue ignoring the working patches without providing an alternative, we are sending the wrong signals to those contributors. H.J. >From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: Moving Linux-specific stuff out of i386-tdep.c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C6D95A.FCEAE1C1@apple.com> References: <200003082121.e28LLRu05681@delius.kettenis.local> X-SW-Source: 2000-q1/msg00623.html Content-length: 2217 Mark Kettenis wrote: > > Hi, > > Over time quite a lot of Linux-dependent stuff has been added to > i386-tdep.c, and I think it's time to move that into its own file. Bear in mind that it should be possible to build a foo-x-linux cross debugger, if for no other reason than to bootstrap new systems. *-nat.c files are by definition native-only, and won't get linked into a cross debugger. I generally like to look at foo-tdep.c as a quasi-library of knowledge about foo. It makes it easier to share code that is the same or nearly the same for different OSes running on the architecture. > But before I do that I'd like to get some clarification on some > issue's. > > 1. Do we still care about the filename limits of older System V > systems? i386-linux-nat.c is longer than 14 characters which is a > no-no according to the GNU conding standards. Well, the systems in question are quite old, we've had long filenames in GDB sources for quite a while, and only the DJGPP folks have whined about it. :-) Personally, I think we should try to stay within the 14-char limit, because a) everything gets unwieldy when people start trying to put the documentation into the filenames like i386-linux-nat-for-red-hat-6.1-beta2-except-in-nepal.c and b) because doschk is a handy way to check on all the filename issues at once. If somebody has an actual System V machine that chokes when handed a tar file with long filenames, now would be a good time to speak up... > 2. Should I postpone creating the new -tdep.c file until after the > release or not. Andrew has been telling us to avoid gratuitous > changes to make it easier to apply outstanding patches. But on the > other hand, after 5.0 is released, I hope to see a lot new patches > generated against 5.0. So creating the new file before 5.0 would > make applying those new patches a lot easier. If the Linux patch backlog were to be emptied out, you wouldn't have this problem. :-) But seriously, if you change it now, before all submitted patches have been dealt with, then it would only be fair for you to adapt those patches yourself. So it seems more like a question of whether you want to do more work now vs later. Stan >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: "H . J . Lu" Cc: Stan Shebs , Mark Kettenis , jtc@redback.com, gdb@sourceware.cygnus.com Subject: Re: A patch for gnu-regex Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38E178BC.67987E6@cygnus.com> References: <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local> <5m4saivyew.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00832.html Content-length: 1723 "H . J . Lu" wrote: > > On Thu, Mar 09, 2000 at 04:53:39PM -0800, Stan Shebs wrote: > > "H . J . Lu" wrote: > > > > > > A GNU/Linux distributor is free to build a GDB that regexp from an > > > > installed glibc. Actually such a distributor is free to do what ever > > > > they like :-) > > > > > > Are you saying as far as gdb is concerned, you have no interests > > > whatsoever in glibc nor helping glibc developers and GNU/Linux > > > distributors? If it is true, that is too bad. > > > > Let's not get all tense here! There's a balance to be struck between > > being self-contained and depending on system stuff, and there's no > > single rule that applies in all cases. For instance, GDB includes > > libiberty, even though many of the functions are available on most > > systems by default, including Linux, but I don't seem to hear anybody > > complaining about that bit of redundancy. (Hmmm, why isn't regex > > in libiberty anyway??) > > > > In the case of GDB on Linux, part of our problem is that we have > > to support GDB on all versions of Linux, not just the latest > > kernel and library. So if there is *any* version of glibc with > > a problematic regex, say one from 4-5 years ago, we need to think > > hard about whether we're going to hose people running a Linux that > > We can put some check to see if regex in glibc is in ok. From > the glibc log in CVS, my simple check seems ok. I can even restrict > it to glibc 2.1 and above. I don't think it should be any problem. FYI, I've put this all on hold until after 5.0. Pokeing around glibc regex is ``on the move''. It continues to be developed and fixed. One thing that has me wondering is i18n and what effect that had on regex. Andrew >From dj@delorie.com Sat Apr 01 00:00:00 2000 From: DJ Delorie To: gdb@sourceware.cygnus.com Subject: Re: Moving Linux-specific stuff out of i386-tdep.c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C6E28D.46F16538@delorie.com> References: <200003082121.e28LLRu05681@delius.kettenis.local> <1000308222742.ZM8876@ocotillo.lan> <20000308173031.A11900@cygnus.com> <1000308225132.ZM8953@ocotillo.lan> X-SW-Source: 2000-q1/msg00629.html Content-length: 930 Kevin Buettner wrote: > Here's what Stan had to say about the matter: > > Names need to be 8.3 unique so djgpp works. The critical files... > The 14-char thing is an old System V limitation, and is... The key thing to note is that 8.3 filesystems truncate the *base* name, not the whole file name. So, verylongfile.c becomes verylong.c and the object file is verylong.o. With SYSV filesystems, verylongfilename.c becomes verylongfilena and the object file is *also* verylongfilena, and it overwrites the source. So, "8.3" means 8.3 *unique*, but longer is OK (like the old FORTRAN rules that variables could be long, but had to be unique in the first six letters) as long as it gets safely truncated. Also note that ftp.gnu.org has a package called "doschk" that checks for 8.3-unique and sysv-14 problems. It's trivial to build and use (ls -1R | doschk) and may prevent problems down the road. >From phdm@macqel.be Sat Apr 01 00:00:00 2000 From: "Philippe De Muyter" To: gdb@sourceware.cygnus.com Subject: gdb and iso-c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003241301.OAA04488@mail.macqel.be> X-SW-Source: 2000-q1/msg00794.html Content-length: 904 Up to some years ago, gdb could be compiled by a K&R C compiler. Now, it can not anymore, and the change seems to be deliberate. It seems to me that the freedom of the gdb users is now restricted compared to the previous versions because of the need of an ISO-C compiler instead of any C compiler to compile it. And I do not understand why the same reasons that apply to binutils and gcc do not hold for gdb. gdb, because it is better than the debugger you get with your operating system, is needed to bootstrap the installation of gas, gld, or gcc in the likely case that not everything works well the first time. Just my opinion Philippe P.S. : I am willing to check that gdb can be compiled by a K&R compiler and submit the needed patches, if that can help. Philippe De Muyter phdm@macqel.be Tel +32 2 702 90 44 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 2 702 90 77 >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: "Frank Ch. Eigler" Cc: gdb@sourceware.cygnus.com, johan.rydberg@netinsight.se Subject: Re: problem with register display Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C7A12A.707179E3@cygnus.com> References: <38C6691D.C3F05223@netinsight.se> X-SW-Source: 2000-q1/msg00641.html Content-length: 524 "Frank Ch. Eigler" wrote: > > And, how do I from gdb call the `sim_info´ function? [...] > > I see no gdb command that hooks to this function. But, one is not > hard to add. Look up the sim option processing functions. They work > from both within gdb (using the "sim" command prefix) and the sim > command line (as long --options). Try ``info target'' (or ``info files''). Looking in gdb/remote-sim.c it would appear that sim_info() is called conditional on there being an executable. I can't think why. Andrew >From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: Eli Zaretskii Cc: Jim Kingdon , Andrew Cagney , gdb@sourceware.cygnus.com Subject: Re: New file gdb/CONTRIBUTE guidelins for the contributor Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A464AF.535C7505@apple.com> References: <38A3B39A.D3C7650C@cygnus.com> <38A3780F.2FE7A510@cygnus.com> <200002111929.OAA13997@mescaline.gnu.org> X-SW-Source: 2000-q1/msg00226.html Content-length: 886 Eli Zaretskii wrote: > > Andrew Cagney writes: > > > > So having said all that, do you still want submit.html or equivalent > > > in the distribution? Having it both places seems like kind of a > > > maintenance pain and seems to me that having the distribution point > > > to the web site probably works. > > > > Yes, I think the GDB distribution should contain the document. > > Perhaps it is better to make this document part of the GDB manual. > Then we could be sure it won't be forgotten due to changing fortunes > of time... The GDB manual is for users only, so not really appropriate there. The internals manual does have a section on contributing, but it could use some tinkering. We should consider installing more links from the web pages to htmlized copies of manuals - that should help improve awareness that the manuals already contain a lot of useful info. Stan >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: tromey@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: 5.0 known issues 2000-02-16 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38BF7E1D.4E0A904D@cygnus.com> References: <38AA42EA.5106E153@cygnus.com> <87ael1ynl8.fsf@cygnus.com> X-SW-Source: 2000-q1/msg00516.html Content-length: 354 Tom Tromey wrote: > > >>>>> "Andrew" == Andrew Cagney writes: > > Andrew> GNU/Linux/i386: > > Without my patch, gdb doesn't work at all when run on x86 Linux boxes > with older kernels (I still run 2.0.34). Tom, I belive JimB's bubbled this up to the top of his queue and made it one of the things try to get into 5.0 Andrew >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: "Gabor Z. Papp" Cc: gdb@sourceware.cygnus.com Subject: Re: gdb cvs Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38BF0551.9B4FE1E@cygnus.com> References: <200003021924.e22JO4U19747@mail.gzp.org.hu> <20000302204824.B18856@gzp.org.hu> X-SW-Source: 2000-q1/msg00514.html Content-length: 299 "Gabor Z. Papp" wrote: > > | cvs server: Updating gdb > | U gdb/CONTRIBUTE > > [...] > > > Is this correct? Were you doing a: ``co gdb'' over the top of an existing tree? I've encountered that message then. I suspect it isn't correct but, from what I saw it still did what I wanted. Andrew >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Benjamin Kosnik Cc: gdb@sourceware.cygnus.com Subject: Re: --target=powerpc-elf broken in current sources? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A8ACD1.E343CD0C@cygnus.com> References: <200002150108.RAA03716@haight.constant.com> X-SW-Source: 2000-q1/msg00280.html Content-length: 406 Benjamin Kosnik wrote: > > > try on older linux release yadda yadda yadda > > No. I haven't. Is gdb only working on older linux releases? To put it another way, is there any thing to suggest that this is a generic build problem or something specific to your Linux host? The powerpc simulator contains some pretty scary linux emulation code. I can imagine that suffering from decay over time. Andrew >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: hjl@lucon.org Cc: blizzard@redhat.com, gdb@sourceware.cygnus.com Subject: Re: problems with gdb Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002181853.e1IIr1t02301@delius.kettenis.local> References: <38A47E89.3F4674B3@mozilla.org> <38AB2DC4.FA9A3C71@redhat.com> <87zot0y99f.fsf@cygnus.com> <38AC0B97.19AE4BAE@mozilla.org> <38AD8469.27616453@redhat.com> <20000218101700.A19913@lucon.org> X-SW-Source: 2000-q1/msg00340.html Content-length: 1098 Date: Fri, 18 Feb 2000 10:17:00 -0800 From: "H . J . Lu" On Fri, Feb 18, 2000 at 12:42:01PM -0500, Chris Blizzard wrote: > Christopher Blizzard wrote: > > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > 0x404cbd41 in ?? () from /lib/libc.so.6 > > (gdb) shar libc.so.6 > > Reading symbols from /lib/libc.so.6...done. > > There are many linuxthreads problems since lin-thread.c was introduced. Unfortunately, I don't have the time to track it down. This isn't one of them (at least the problem that was origionally reported by Jim Kingdon). The bug report is from before lin-thread.c was introduced. As a matter of fact, I have seen a spurious SIGTRAP on Solaris 2.6 too in the gdb.threads/pthreads test. And I also see them quite frequently on the Hurd too (where every program is multithreaded). Looks like there is something wrong in the platform independent threads code. As for the "many linuxthreads problems": would you please tell us what they are. Apart from the spurious SIGTRAPs I'm not aware of any. Mark >From jsm@cygnus.com Sat Apr 01 00:00:00 2000 From: Jason Molenda To: Todd Whitesel Cc: GDB Developers Subject: Re: GDB ftp site in hyperspace ... Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000131225201.A11482@cygnus.com> References: <200002010648.WAA28893@alabama.wrs.com> X-SW-Source: 2000-q1/msg00082.html Content-length: 707 On Mon, Jan 31, 2000 at 10:48:42PM -0800, Todd Whitesel wrote: > I just tried to ftp a fresh tarball of 4.18, but the ftp.cygnus.com site > claims the directory has moved to sourceware, yet the /pub/gdb directory > on sourceware appeared empty... > > I used the shell ftp client on solaris... What gives? The shell ftp client on Solaris is broken. Use another client, such as ncftp or netscape, to browse the ftp site. Or use another OS, say... oh I don't know... maybe Linux? :-) (I'm not joking about the Solaris ftp client being broken; I think it will still work if there is at least one file in a given directory. The directory you're looking at has no files in it, only subdirectories) Jason >From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: gatliff@haulpak.com Cc: gdb@sourceware.cygnus.com Subject: Re: gdbstubs library posted at sourceforge Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200001271910.OAA04242@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00062.html Content-length: 849 > I just moved my gdbstubs library to sourceforge.net. Cool! I've added a link from http://sourceware.cygnus.com/gdb/ - at the bottom of the page with the other links. > The release license is LGPL. Are you sure you want this rather than public domain (as the stubs in the GDB distribution) or XFree86-style? I suppose maybe it is a moot point if people leave out the stubs when they actually ship code, but in general, the LGPL's requirement that people make available .o's makes it somewhat impractical for many embedded applications. > I'll also take any suggestions on how to manage the project--- I'm not > exactly skilled in the art of extreme multitarget development, at > least not yet. :^) You've already done the hard part by being dumb ^H^H^H^H brave enough to start the project! Feel free to ask if you have specific questions. >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: kettenis@wins.uva.nl Cc: muller@cerbere.u-strasbg.fr, gdb@sourceware.cygnus.com Subject: Re: RFD: New command to inspect other selectors memory. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003040704.CAA08168@indy.delorie.com> References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr> <200003031240.e23CeRn00162@delius.kettenis.local> X-SW-Source: 2000-q1/msg00536.html Content-length: 170 > The suggested syntax could probably be > improved, since "xx" isn't very descriptive. People with bright ideas? How about "x/seg=SEG OFFSET"? Or simply "x SEG:OFF"? >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Discussion Cc: GDB Patches Subject: [MAINT] Anthony Green - Java Maintainer Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C71B06.94E21103@cygnus.com> X-SW-Source: 2000-q1/msg00631.html Content-length: 2168 Hello, I've made Anthony Green the Java maintainer. enjoy, Andrew Thu Mar 9 14:21:07 2000 Andrew Cagney * MAINTAINERS (Core): Anthony Green is the Java - including testsuite - maintainer. Reformat testsuite and language support sections Index: MAINTAINERS =================================================================== RCS file: /cvs/src/src/gdb/MAINTAINERS,v retrieving revision 1.21 diff -p -r1.21 MAINTAINERS *** MAINTAINERS 2000/03/05 08:46:56 1.21 --- MAINTAINERS 2000/03/09 03:26:56 *************** maintainers when resolving more generic *** 56,62 **** The host maintainer ensures that gdb (including mmalloc) can be built as a cross debugger on their platform. - hp testsuite (gdb.hp) *Jimmy Guo adl-debugger-wdb-merge-guru@cup.hp.com djgpp native *Eli Zaretskii eliz@gnu.org DJ Delorie dj@cygnus.com MS Windows (N.T., CE, '00) host & native --- 56,61 ---- *************** tracing Michael Snyder msnyder@cygnus *** 90,96 **** threads Michael Snyder msnyder@cygnus.com breakpoint.c Michael Snyder msnyder@cygnus.com language support David Taylor taylor@cygnus.com ! C++ language support Daniel Berlin dan@cgsoftware.com expression eval David Taylor taylor@cygnus.com defs.h David Taylor taylor@cygnus.com utils.c David Taylor taylor@cygnus.com --- 89,96 ---- threads Michael Snyder msnyder@cygnus.com breakpoint.c Michael Snyder msnyder@cygnus.com language support David Taylor taylor@cygnus.com ! C++ support Daniel Berlin dan@cgsoftware.com ! Java support Anthony Green green@cygnus.com expression eval David Taylor taylor@cygnus.com defs.h David Taylor taylor@cygnus.com utils.c David Taylor taylor@cygnus.com *************** rdi/adp protocol Fernando Nasser fnasse *** 108,113 **** --- 108,115 ---- gdbserver Stan Shebs shebs@apple.com documentation Stan Shebs shebs@apple.com testsuite Stan Shebs shebs@apple.com + hp tests (gdb.hp) *Jimmy Guo adl-debugger-wdb-merge-guru@cup.hp.com + Java tests (gdb.java) Anthony Green green@cygnus.com Kernel Object Display Fernando Nasser fnasser@cygnus.com >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: ac131313@cygnus.com Cc: muller@cerbere.u-strasbg.fr, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com Subject: Re: RFD: New command to inspect other selectors memory. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003040706.CAA08171@indy.delorie.com> References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr> <38BFB50A.606036CF@cygnus.com> X-SW-Source: 2000-q1/msg00537.html Content-length: 232 > The theory is that if ``CORE_ADDR'' is made in to a pretend object > (ISO-C remember :-) and then the rest falls out.... As they say, the > proof is left as an exercise to the reader. Sorry, I don't follow. Can you elaborate?