From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Jim Blandy Cc: gdb@sourceware.cygnus.com Subject: Re: unused parameter warnings Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38E12AE4.EA41F776@cygnus.com> References: <200003281907.OAA14473@zwingli.cygnus.com> X-SW-Source: 2000-q1/msg00828.html Jim Blandy wrote: > Jim, just FYI, GDB currently set -Wunused for the reason you've explained (it is also why I've been picking at a -Wno-unused-param flag). gdb/configure.in doesn't enable it. The reason you're seeing those warnings is because the top level src/Makefile.in sets: CFLAGS="-g -Wall -O2" overriding any local default. Having the top level Makefile.in ``impose'' a specific -W policy is something to discuss with the other projects. enjoy Andrew >From insulaner_andi@yahoo.com Sat Apr 01 00:00:00 2000 From: Andreas Kuepper To: gdb@sourceware.cygnus.com Subject: running GDB on Cygwin Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000303101528.22003.qmail@web3402.mail.yahoo.com> X-SW-Source: 2000-q1/msg00518.html Content-length: 364 Is there anybody who ever tried to run GDB on Cygwin? I want to do remote debugging and when I run "configure" it fails with the message : configure: error: could not find term library Thanks for your help! Andreas Kuepper __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com >From msnyder@cygnus.com Sat Apr 01 00:00:00 2000 From: Michael Snyder To: Eli Zaretskii Cc: Jim Blandy , hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Problems with hardware watchpoint on ia32. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38D92F29.A3D@cygnus.com> References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091210.HAA19857@indy.delorie.com> <200003221806.NAA14225@indy.delorie.com> X-SW-Source: 2000-q1/msg00774.html Content-length: 759 Eli Zaretskii wrote: > > > Eli's test of the value's type is incorrect if the watch expression > > contains a structure comparison, like (foo == bar) || (something > > else), where foo and bar are structures. In that case, there will be > > a value of type "struct", not at the end of the value list, but which > > should be watched in its entirety. > > Errr... do you have an actual example program where this happens? > > I seem to be unable to reproduce the problem, at least in a C program: > whenever I say "watch foo == bar" (where foo and bar are structs), GDB > curses thusly: > > Structure has no component named operator==. Argh... gdb does not seem to know that struct compare is permitted. I'll publish a patch. Michael Snyder >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: kettenis@wins.uva.nl Cc: gdb@sourceware.cygnus.com Subject: Re: Restructuring i386_extract_return_value Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003101742.MAA22060@indy.delorie.com> References: <200003092241.e29Mfow00303@delius.kettenis.local> X-SW-Source: 2000-q1/msg00671.html Content-length: 908 > Comments are welcome! The changes seem okay, but I have one consideration: > 1. The majority of i386 targets in GCC return floating-point values by > default on the FPU stack. In fact the only exception is NeXT. > There is a switch `-mno-fp-ret-in-387' to force GCC to return > floating-point values in the ordinary CPU registers. I don't think > this can be determined from the debugging information. Is it worth > adding a i386 target specific option to enable people to debug > this code? Propably not. Is this switch so painful to support that it is justified to disable debugging such programs? In my experience, about 5 minutes after you release a product based on the assumption that this switch is not used enough to care about, somebody posts a bug report for a program which does use that switch... So I think it might be a good idea to support it if that is feasible. >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Discussion Cc: GDB Patches Subject: [GDB-MAINT] Nick Duffek is now the UnixWare threads maintainer Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A78889.1CFDD70@cygnus.com> X-SW-Source: 2000-q1/msg00257.html Content-length: 863 Hello, Nick was the original author of the UnixWare threads support. It's only natural that he be allowed to continue maintaining it. Andrew Mon Feb 14 15:39:01 2000 Andrew Cagney * MAINTAINERS: Make Nick Duffek the UnixWare threads maintainer. Index: MAINTAINERS =================================================================== RCS file: /cvs/src/src/gdb/MAINTAINERS,v retrieving revision 1.3 diff -p -r1.3 MAINTAINERS *** MAINTAINERS 2000/02/12 23:55:14 1.3 --- MAINTAINERS 2000/02/14 04:40:59 *************** GNU/Linux PPC native Kevin Buettner kev *** 41,46 **** --- 41,47 ---- hurd native Mark Kettenis kettenis@wins.va.nl macos host & native Stan Shebs shebs@apple.com hpux, hp pa native Jeff Law law@cygnus.com + UnixWare Threads Nick Duffek nsd@cygnus.com Core: Generic components used by all of GDB >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: hjl@valinux.com Cc: gdb@sourceware.cygnus.com Subject: Re: Problems with hardware watchpoint on ia32. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003081008.FAA16481@indy.delorie.com> References: <20000307132401.A20282@valinux.com> X-SW-Source: 2000-q1/msg00595.html Content-length: 1624 > Starting program: /home/hjl/bugs/gdb/hw/y > warning: Could not insert hardware watchpoint 1. > warning: Could not insert hardware watchpoint 3. > ptrace: Unknown error 4294967295. > Cannot insert breakpoints. > The same program may be running in another process. > (gdb) > > ia32 only has 4 hardware debug registers. But gdb shouldn't crash. I don't see any crashes in the above script. GDB simply didn't start the process. It is arguable whether it should instead proceed after inserting only those watchpoints it can, but I agree that it should at least be a user option. > Even worse, after deleted one hardware watchpoint, gdb still refused > to work. It works for me, but I have patches to do that, which I'm trying for 6 months to get accepted :-(. Those patches also correct numerous other problems with watchpoints on x86, which you didn't mention. For example, try setting several watchpoints (of different types) on the same variable, and see the mess. Another problem which I corrected is that you cannot watch struct members, array elements, and bit fields with hardware-assisted watchpoints. > (gdb) watch a1 > Watchpoint 1: a1 > (gdb) watch a2 > Watchpoint 2: a2 > (gdb) > > gdb won't set hardware watchpoints on long long nor double. You could look at go32-nat.c, it supports watching any region up to 16 bytes large. (I'm at a loss how come DJGPP needed to invent this: I'd expect any x86 platform to have this already, since watchpoints are such an indispensable tool in some circumstances.) > I will send in a patch in another email. Please see my response with objections to your patch. >From scottb@netwinder.org Sat Apr 01 00:00:00 2000 From: Scott Bambrough To: GDB Mailing List Subject: Problems with LinuxThreads support in GDB... Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C92CBD.178D0A1E@netwinder.org> X-SW-Source: 2000-q1/msg00670.html Content-length: 1430 > Scott Bambrough wrote: > > > > I've been running tests on the ARM Linux target on a NetWinder regularly. The > > results of the testsuite follow. Most of the problems are due to no > > linuxthreads support and problems stepping in/out or backtracing in signal > > handlers. I'll work at implementing support for these over time. I was hoping > > to port the x86 work, but just haven't had the time. > Michael Snyder wrote: > > Hmm, the new thread_db module should be pretty > target-independent (correct me if I'm wrong). Ok. I attempted to put the linuxthreads support in last night. It was relatively painless, but I have reached a stumbling block with glibc 2.1.2. In gdb_proc_service.h there are the following two definitions: #ifndef HAVE_PRGREGSET_T typedef gregset_t prgregset_t; /* BOGUS BOGUS BOGUS */ #endif #ifndef HAVE_PRFPREGSET_T typedef fpregset_t prfpregset_t; /* BOGUS BOGUS BOGUS */ #endif The BOGUS comments are accurate. Neither gregset_t or fpregset_t are defined in . prgregset_t and prfpregset_t are also used in gdb_threads_db.h as well without checking the defines from config.h. I'm trying this on 2.1.3 ATM, but for the most part, the installed base of users is using 2.1.2 on ARM Linux. Any thoughts on how I could get around this? Scott -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org >From guo@cup.hp.com Sat Apr 01 00:00:00 2000 From: Jimmy Guo To: gdb@sourceware.cygnus.com Subject: hppa 10.20 test result comparison Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: X-SW-Source: 2000-q1/msg00778.html Content-length: 3207 This is a comparison of 2/4's gdb and 3/21's. The sourceware version of 3/21 has disabled elf32-hppa support in bfd, so there's no hpux 11.00 comparison for the sourceware version. Also, I've just diff'd the result for run PASS "1", which is HP WDB project's internal pass for HP compiler support. I don't have the result for GNUPro gcc / g++ pass yet. So far, the 3/21 version is mostly stable, with some regressions when using HP compilers. - Jimmy Guo, guo@cup.hp.com <0>: 2/4 # of expected passes 4505 # of unexpected failures 101 # of unexpected successes 3 # of expected failures 17 # of unresolved testcases 2 # of unsupported tests 15 <1>: 3/21 # of expected passes 4499 # of unexpected failures 115 # of unexpected successes 3 # of expected failures 17 # of unresolved testcases 2 # of unsupported tests 16 ------------------------------------------------------------------------ Section - FAIL / XFAIL / XPASS / UNRESOLVED | 1 |: (P:PASS F:FAIL FTM:FAIL/timeout XFA:XFAIL XTM:XFAIL/timeout XPA:XPASS UNR:UNRESOLVED SKI:skipped '-':not run) ------------------------------------------------------------------------ gdb.base/selftest.exp <0>: | P |: step into xmalloc call <1>: | F |: step into xmalloc call <0>: | P |: xgdb is at prompt <1>: | F |: xgdb is at prompt <0>: | P |: send ^C to child process <1>: |FTM|: send ^C to child process <0>: | P |: send SIGINT signal to child process <1>: |FTM|: send SIGINT signal to child process <0>: |XFA|: backtrace through signal handler <1>: |XTM|: backtrace through signal handler gdb.base/shlib-call.exp <0>: | P |: run until breakpoint set at a function <1>: | F |: run until breakpoint set at a function gdb.base/so-impl-ld.exp <0>: | P |: step into solib call <1>: | F |: step into solib call <0>: | P |: step in solib call <1>: | F |: step in solib call gdb.base/so-indr-cl.exp <0>: | P |: break on indirect solib call before running <1>: | F |: break on indirect solib call before running gdb.base/solib.exp <0>: | P |: caught generic solib load <1>: | F |: caught generic solib load <0>: | P |: continue after generic catch load <1>: | F |: continue after generic catch load <0>: | P |: caught generic solib unload <1>: | F |: caught generic solib unload <0>: | P |: caught specific solib load <1>: | F |: caught specific solib load <0>: | P |: caught specific solib unload <1>: | F |: caught specific solib unload <0>: | P |: specific catch load doesn't trigger inappropriately <1>: | F |: specific catch load doesn't trigger inappropriately <0>: | P |: specific catch unload doesn't trigger inappropriately <1>: | F |: specific catch unload doesn't trigger inappropriately <0>: | F |: break on indirect call <1>: | P |: break on indirect call <0>: | F |: continue to break on indirect call: the program is no longer running <1>: | - |: continue to break on indirect call: the program is no longer running <0>: | - |: continue to break on indirect call <1>: | F |: continue to break on indirect call