From mboxrd@z Thu Jan 1 00:00:00 1970 From: Donn Terry To: "'gdb@sourceware.cygnus.com'" Cc: "'mark@codesourcery.com'" Subject: Regressions problem (200 failures) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-ID: X-SW-Source: 2000-q1/msg00475.html Message-ID: <20000401000000.28gleBwuF35TA35PRyb0veXPIPohNjBsDli2VJCPXO0@z> Andrew has asked me to see if there are others affected by this... On 2/17, the following patch was made to gcc: > 2000-02-17 Mark Mitchell > > * function.c (thread_prologue_and_epilogue_insns): Put a line note > after the prologue. It has the effect, in my case at least, of causing gdb to break at the "{" of many functions when breaking at a function name (5 of 5 main()s that I tried, but not too many other functions). (Usually gdb breaks breaks at the first statement rather than somewhere in the function prologue). I discussed this with Mark Mitchell, and he concurs that that could be a side-effect of the patch (whose purpose is to assure that SOME breakpoint occurs at the beginning of each function). That, in itself, isn't a problem (except possibly with user perception). However, the gdb regressions are written in such a way that they expect to stop at the first statement (and often do a single "n", expecting the first statement to be executed). This causes well over 200 (mostly cascade) regression failures. Andrew asserts that the regressions aren't being too picky in this regard because of user expectation. The problem for me is I suspect that they're BOTH right, but there are regression failures unless something happens. Are there others out there who are seeing this (run the regressions pointing it at a new gcc)? (The gcc CVS as of 5:30 or so PST last night still exhibited the problem.) Does anyone have any thougts on how to proceed? Donn Terry Speaking, of course, only for myself. >From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000 From: Elena Zannoni To: Eli Zaretskii Cc: Pierre Muller , gdb@sourceware.cygnus.com, Elena Zannoni Subject: Re: Buffering problems with "gdb < foo" Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <14533.8241.716311.478074@kwikemart.cygnus.com> References: <200003070845.JAA27855@cerbere.u-strasbg.fr> <200003070851.DAA14463@indy.delorie.com> X-SW-Source: 2000-q1/msg00559.html Content-length: 3075 Eli Zaretskii writes: > > > dir needs no confirmation if not invoked from tty ! > > Did you actually look at the from_tty variable's value inside > dir_command? I don't have the GDB 5.0 binary here, but GDB certainly > *does* ask for confirmation if invoked with stdin and stdout > redirected, at least in the DJGPP version. Elena, is that a bug? > When I try this on solaris, in directory_command(), from_tty is 1, but the query() function is the one that finds out that it shouldn't ask the question to the user. int query (char *ctlstr,...) { va_list args; register int answer; register int ans2; int retval; va_start (args, ctlstr); if (query_hook) { return query_hook (ctlstr, args); } /* Automatically answer "yes" if input is not from a terminal. */ if (!input_from_terminal_p ()) return 1; [...] } This input_from_terminal_p() function does: int input_from_terminal_p () { return gdb_has_a_terminal () && (instream == stdin) & caution; } In my case the gdb_has_a_terminal() returns 0, so the query is not asked. All seems to work fine fro solaris. What happens on DJGPP? Is gdb_has_a terminal() returning 1, maybe? > Anyway, the basic point is still valid, even if this particular > example is not: when stdin is redirected to a file, GDB should turn > editing off. Or just assume that all the queries have yes as automatic answer, which is what I always thought it was doing. > > > I think its because y is not a valid GDB command ! > > Invalid commands don't cause GDB to exit, they just result in an error > message. It would be inconceivable to have GDB exit every time I > mistype a command ;-). Yes, the 'y''s are just generating errors. Here is what I get: kwikemart.cygnus.com: 9 % cat commands file testsuite/gdb.base/break dir y dir . break main run q y kwikemart.cygnus.com: 8 % ./gdb -nw -nx < commands GNU gdb 4.18.1 (UI_OUT) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.5.1". (gdb) file testsuite/gdb.base/break Reading symbols from testsuite/gdb.base/break...done. (gdb) dir Source directories searched: $cdir:$cwd (gdb) y Undefined command: "y". Try "help". (gdb) dir . Source directories searched: /kwikemart/homer/ezannoni/flathead-dev/solaris/gdb:$cdir:$cwd (gdb) break main Breakpoint 1 at 0x10824: file /kwikemart/marge/ezannoni/flathead-dev/devo/gdb/testsuite/gdb.base/break.c, line 75. (gdb) run Starting program: /kwikemart/homer/ezannoni/flathead-dev/solaris/gdb/testsuite/gdb.base/break Breakpoint 1, main (argc=1, argv=0xeffff124, envp=0xeffff12c) at /kwikemart/marge/ezannoni/flathead-dev/devo/gdb/testsuite/gdb.base/break.c:75 75 if (argc == 12345) { /* an unlikely value < 2^16, in case uninited */ (gdb) q Elena >From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: "H . J . Lu" Cc: Mark Kettenis , shebs@apple.com, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: A patch for gnu-regex Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5mvh2yugpy.fsf@jtc.redbacknetworks.com> References: <20000307134103.A20533@valinux.com> <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> <20000307211842.C1573@lucon.org> X-SW-Source: 2000-q1/msg00589.html Content-length: 1401 >>>>> "hjl" == H J Lu writes: hjl> The current master copy of GNU regex is in glibc. I'd like to be hjl> able to compile gdb on a known good glibc base system using the hjl> GNU regex in glibc. The problem, as I see it, with linking with a host's regex library is that gdb does not know whether or not it is "good". We could write an autoconf test that attempts to verify the library, or some heuristic like __GLIBC__ && __GLIBC__ >= 2, but neither is as safe as using the known good version of the library that is bundled with GDB. One could argue that if we're worried about regex, why aren't we worried about a hundred other things and provide local copies of them. I'll concede that that would be silly, but I believe that historical problems with the regex code makes it a special case. Having said all that, I'm not opposed to using the host regex. I'd like to see us change the regex usage within GDB to use the POSIX.2 API so that we can link with any modern hosts library. But since the benefits are small and the risks large, I think it's not the type of change we want to be making while were trying to wrap up a release. hjl> I don't want to spend time to check if gdb has the updated regex hjl> or not. It doesn't matter much to me. It's a known good implementation that works well enough for GDB's purposes. --jtc -- J.T. Conklin RedBack Networks >From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: Jim Kingdon Cc: gdb@sourceware.cygnus.com Subject: Re: Status Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A48875.B520ED34@apple.com> References: <38A34041.B443DAFB@apple.com> <38A46C5C.F8301644@apple.com> <200002112037.PAA02309@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00233.html Content-length: 1623 Jim Kingdon wrote: > But I guess the GCC system makes sense to me. If something is enough > of an issue to be a "technical controversy" in the sense of something > people would escalate to the chief technical maintainer/team, you kind > of want to get people on board as much as possible. Because if you > proceed without _some_ level of consensus (not among the whole world, > but at least among a small group of people most involved), then it > creates various kinds of pain. > > I mean, there is almost always a way out (e.g. make it an option or > something, if there really a demand for both solutions). The hard part comes when somebody has to make a single choice. For instance, Linus has often had to make arbitrary decisions, in some cases without necessarily being the big PCMCIA-PS/2-bridge :-) expert. But in general people agree that his involvement has been better for Linux' continued evolution than not. Could a committee have done as well? Hard to say. > One thing I don't want to be single-string is the process of making > checkins which are believed to be relatively uncontroversial. Right > now there is a big problem when the person listed in MAINTAINERS for a > particular file gets busy or is on vacation or whatever. Or to put it > another way, being a maintainer should grant you the right to overrule > other people but it shouldn't grant you the right to stop things in > their tracks. Or something like that. Absolutely. I hope that every maintainer has sent in their login info and ssh keys and all, there should be no obstacle to them making their own commits now, right? Stan >From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: Daniel Berlin Cc: gdb@sourceware.cygnus.com Subject: Re: Another Issue for 5.0 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38AC4EC7.E3F1EEDE@apple.com> References: X-SW-Source: 2000-q1/msg00332.html Content-length: 1054 Daniel Berlin wrote: > > IMHO, the overload resolution for DWARF2/STABS/all non-hp platforms should > really be fixed for 5.0. > I have patches to do this (in fact, i'm about to send another jumbo patch > to gdb-patches with it all combined so i don't have to keep emailing it to > people :P), with no regressions, well, actually, that's not true. > Some overload resolution things that were xfail before in the testsuite > now pass. > Sorry about that. I'll try to make sure i keep the broken things broken in > the future. :P :-) > But, anyway, i get about 5-10 emails a week asking for those patches. > Even on HP using aCC, where overload resolution works, you get benefits > because i added support for references in overloads, and fixed a problem > where the compares against function names were whitespace sensitive where > they shouldn't have been (so operator [] would be considered the same > function as operator[] when we were hunting down overloads). This all sounds great! Are there any obstacles to just installing the patches? Stan >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Mark Kettenis Cc: dan@cgsoftware.com, gdb@sourceware.cygnus.com Subject: Re: Odd, ptrace_getregs Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38CDE483.C09982B8@cygnus.com> References: <200003131833.TAA19979@landau.wins.uva.nl> X-SW-Source: 2000-q1/msg00693.html Content-length: 505 Mark Kettenis wrote: > I was silently hoping nobody would notice :-(. I corrected a typo in > configure.in, but forgot to run autoconf before checking it in. It's > basically harmless since it is only the printing of the value that's > broken. I just hoped that someone would find the need to regenerate > configure soon. Feel free to check in a regenerated autoconf. Have a look for the fateful phrase ``Fix typo.'' in the ChangeLogs :-) It should make you feel like you're not alone :-) Andrew >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Jason Molenda Cc: gdb-testers@sourceware.cygnus.com, 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: <389F6110.A54017D@cygnus.com> References: <389EC815.BC34F3E6@cygnus.com> <20000207112957.A27486@cygnus.com> X-SW-Source: 2000-q1/msg00140.html Content-length: 2240 Jason Molenda wrote: > > On Tue, Feb 08, 2000 at 12:26:45AM +1100, Andrew Cagney wrote: > > > With that in mind, I've tentatively planned: two weeks of > > patch resolution; the cutting of the 5.0 branch (2000-02-21?); one week > > of last minute checks; and then the 5.0 release (29/2 2000-02-29?). > > (Everyone is free to roll on the floor laughing at this point :-) > > I think this is too aggressive. If we had the old source base, maybe it > would be tenable, but the new repository has mixed the old GDB sources > with a BFD that hasn't been sync'ed for something like six months. > And there hasn't been a binutils release in over a year and a half--so > the stability of binutils across a wide array of platforms has to be > considered. I make an ambid claim, everyone else steps up to the table with their personal agenda, we all start to negotiate .... :-) > Maybe it would be better to get some test results from a variety of common > Unix platforms and decide based on how things look. NB cygwin support > in binutils is noticably broken -- it will take at least a little work > to get that resolved. Yes, more than anything else I should be interested build/test results. Thanks for reminding me :-) > On the other hand, I do agree that a release will go much more smoothly > now that the repository is on sourceware. Yes, turn around time once a patch is approved is going to tend to zero. Ya! Any way, you will have noticed that I've (for the first time ever?) given an approximate date for the major release that will follow 5.0. I've done it for two reasons: o to make it clear how quickly this release really should come out. o to make it clear that if something misses the 5.0 boat then 5.1 will be departing less than 6 months later. Given that this is a real departure from GDB's previous habits (1-2 year release cycles) I suspect I'm going to have difficulty convincing people - I can but try :-). I think of 5.0 as a consolidation of the significant amount of re-engineering that has gone on over the last year. For it I'm only going to be worried about major failures or serious losses of functionality. Enhancements are for 5.1. > MHO Always more than welcome :-) enjoy, Andrew >From hjl@lucon.org Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: GDB Subject: Does gdb support calling C++ member functions? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000114080427.A23281@lucon.org> X-SW-Source: 2000-q1/msg00032.html Content-length: 105 Does gdb support calling C++ member functions? I cannot get it to work. Any suggestions? Thanks. H.J. >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Paul Breed Cc: gdb@sourceware.cygnus.com Subject: Re: GDB/Coldfire bug Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38AA4E9A.87C39EFA@cygnus.com> References: <20000125215209.14490.qmail@web3501.mail.yahoo.com> X-SW-Source: 2000-q1/msg00306.html Content-length: 1451 Paul Breed wrote: > > I'm a bit lost on how to solve my GDB problem. > If this is the wrong newslist can you suggest the > proper one? > > I am trying to use GDB/Insite in a cross compiler > environment. I have a S/W GDB Stub running on the > Coldfire. It seems to work great. > > GDB seems to have some problems.... > c -> continue works. > s -> Step works. > break x -> works. > info locals works etc... > > n ->Step over does not work. It tries to read > things off the stack and gets confused. > > >From what research I've done online I believe this > problem is not really GDB, I believe it is a problem > with the debugging information generated by the > compiler. (gcc 2.95.2 configured for m68k-elf) Ah. m68k. One thing. I recently fixed a bug to do with m68k stack dumps - a back trace would fall off the end of the stack. Was this with the most recent version of GDB? Andrew Wed Dec 8 19:56:48 1999 Andrew Cagney * frame.h, blockframe.c: Rename default_frame_chain_valid to file_frame_chain_valid. Rename alternate_frame_chain_valid to func_frame_chain_valid. * config/sparc/tm-sparclite.h, config/mips/tm-mipsv4.h, config/m88k/tm-delta88v4.h, config/m68k/tm-m68kv4.h, config/m68k/tm-monitor.h, config/i386/tm-i386nw.h, config/i386/tm-i386v4.h, config/h8300/tm-h8300.h: Update. * mips-tdep.c (mips_gdbarch_init): Update. >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: eliz@delorie.com Cc: gdb@sourceware.cygnus.com Subject: Re: i386_register_raw_size[] Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002232100.e1NL0nE00718@delius.kettenis.local> References: <200002231928.OAA18661@indy.delorie.com> X-SW-Source: 2000-q1/msg00387.html Content-length: 2799 Date: Wed, 23 Feb 2000 14:28:19 -0500 (EST) From: Eli Zaretskii i386-tdep.c defines the array used to compute REGISTER_RAW_SIZE thusly: /* i386_register_raw_size[i] is the number of bytes of storage in the actual machine representation for register i. */ int i386_register_raw_size[MAX_NUM_REGS] = { 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 10, 10, 10, 10, 10, 10, 10, 10, 4, 4, 4, 4, <<<<< 4, 4, 4, 4, <<<<< 16, 16, 16, 16, 16, 16, 16, 16, 4 }; The registers marked with "<<<<<" are the ones I want to discuss. These are control, status, and tag words, and the FP instruction address and operands. The ``raw'' part of the name and the comment imply that these should have the same size as they are saved by the low-level debug support functions on the target machine. I interpret that as the layout in memory of the data saved by FSAVE and similar instructions. I think ``raw'' implies that the data isn't yet interpreted by GDB yet, i.e. it is in the target byte order. However, the above definition of i386_register_raw_size[] does not follow the FPU state layout as saved by FSAVE. For example, the actual length of the control/status/tag words is 2 bytes, not 4, and the last register, the opcode occupies the 2 upper bytes of the same 4-byte word as the FP instruction selector. Messy ain't it? That, the fact that there exist other i386 instructions that use a different layout to store the same data, and the possibility of other OS'es that present the data ina very different layout, were the reasons to simply pretend that these are 32-bit registers. This was discussed in detail last fail. I believe the start of the thread is: http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00033.html I don't have any problems to create an illusion in go32-nat.c that the FP register layout is like implied by i386_register_raw_size[], especially if it turns out that DJGPP is the only x86 target which doesn't already comply with this layout. But is this really the intent--to have all x86 targets use the same raw layout of registers, and if so, why do we need the corresponding virtual_size array and macros? Yes, that's what you are supposed to do! Look at i386gnu-nat.c and i386-linux-nat.c to see examples. It is really the intent to have the same layout on all x86 targets, since this makes it easier to use the same GDB for different x86 targets. The virtual_size array and the macro's are still necessary, since the raw data still needs to be interpreted to take into account differences in endianness or floating point types if GDB runs on a host with a different architecture than the target. Mark >From brg@sartre.dgate.ORG Sat Apr 01 00:00:00 2000 From: "Brian R. Gaeke" To: Stan Shebs Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com Subject: Re: Should GCC tell GDB about its optimizations? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000303173847.A1487@celes.dgate.ORG> References: <38C051C3.260D666B@apple.com> X-SW-Source: 2000-q1/msg00532.html Content-length: 1596 And then spake Stan Shebs, as follows: > Ideally of course, GCC would issue lots of amazingly detailed debug info, > and GDB would use it to reconstruct and report program state just as the > programmer expects to see it. But today, the result is just lame; hackers > trying to debug get lots of squirrelly behavior from GDB. The problem is > that they don't know whether the randomness is due to bugs in the program, > or to the effect of the optimizer. So the suggestion came up to have GCC > issue debug info stating what optimizations have been applied to a file, > and to have GDB report that information per-function, so that users could > lower their expectations appropriately. You may (or perhaps may not) find some of the material Caroline Tice has worked on here at UCB useful -- ISTR she was investigating debugging optimized code and did work on a compiler that outputted a lot of information on the transformations that were applied to the code (and debugging tools that used it.) Disclaimer: I don't have any direct knowledge of how her code did what it did, so I can't really be of much help -- but I just thought that her dissertation talk sounded a lot like what you are trying to do... http://sunsite.berkeley.edu/Dienst/UI/2.0/Describe/ncstrl.ucb/CSD-99-1077 http://www.cs.berkeley.edu/~cmtice/ -Brian -- Brian R. Gaeke, brg@sartre.dgate.ORG -- PGP/GPG gleefully accepted "the iguana / in the petshop window on St Catherine Street / crested, royal-eyed, ruling / its kingdom of water-dish and sawdust / dreams of sawdust" - Margaret Atwood, "Dreams of the Animals" >From Rene.Affourtit@pemstar.nl Sat Apr 01 00:00:00 2000 From: Rene.Affourtit@pemstar.nl To: ecos-discuss@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: cl7111 and gdb problem Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: X-SW-Source: 2000-q1/msg00756.html Content-length: 2154 hello, I have a question concerning the use of the arm-elf-gdb debugger and the CL7111-2 development board. When trying to talk to angel in the cl7111 board using the rdi protocol as described in the documentation gdb prints the following message: "RDI_open: undefined error message, should reset target" and does not respond anymore. I was wondering if anyone else has experienced this problem. There was a similar message in feb. 2000 (subject line : Problem using Insight on ARM7 PID for debugging a ecos application), but I could not find an answer in the mailing list archive. any help will be appreciated. Rene Affourtit BTW: Is anybody else using the cl7111 target? Teh target system uses Angel version 1.04. bash.exe-2.02$ arm-elf-gdb --version GNU gdb 4.17-ecosSWtools-arm-990321 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. This version of GDB is supported for customers of Cygnus Solutions. Type "show warranty" for details. This GDB was configured as "--host=i586-cygwin32 --target=arm-elf". bash.exe-2.02$ bash.exe-2.02$ arm-elf-gdb GNU gdb 4.17-ecosSWtools-arm-990321 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. This version of GDB is supported for customers of Cygnus Solutions. Type "show warranty" for details. This GDB was configured as "--host=i586-cygwin32 --target=arm-elf". (gdb) set remotebaud 115200 (gdb) target rdi com1 DEBUG: Buffer allocated in angel_RDI_open(type=10). negotiate_params sent negotiate packet RDI_open: undefined error message, should reset target DEBUG: Entered angel_RDI_info. DEBUG: RDIInfo_Target. wait_for_debug_message waiting for 80010001 (indented lines are debug information genrated by gdb (rebuilt gbb with debug info on in ardi.c)