From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Faylor To: Eli Zaretskii Cc: toddpw@windriver.com, gdb@sourceware.cygnus.com Subject: Re: Readline and -DMINIMAL Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000331212807.A2696@cygnus.com> References: <200003281230.EAA15638@alabama.wrs.com> <20000328105123.G27306@cygnus.com> <200003312329.SAA07193@indy.delorie.com> X-SW-Source: 2000-q1/msg00854.html On Fri, Mar 31, 2000 at 06:29:30PM -0500, Eli Zaretskii wrote: >> The readline directory in CVS is version >> 4.0 with changes from Eli Zaretskii (I hope he also notified the readline >> maintainer about these) to get things working on DJGPP. > >I checked my patches against the recent beta version of Readline, and >all the changes are already taken care of there (the person who ported >Bash to DJGPP submitted almost identical patches to the Readline >maintainer). That's good to hear. I guess we should think about importint the newest readline sometime after 5.0 branches. cgf >From sb@metis.no Sat Apr 01 00:00:00 2000 From: Steinar Bang To: Jason Molenda Cc: Bryce McKinlay , Takis Psarogiannakopoulos , gdb@sourceware.cygnus.com Subject: Re: SHARED LIBS Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <385AF8A8.95EF6BD4@albatross.co.nz> X-SW-Source: 2000-q1/msg00018.html Content-length: 4033 [Please cc me in any responses, as I'm not on the gdb list. Thanx!] On Fri, 17 Dec 1999 22:34:07 -0800, Jason Molenda wrote: [...] > This is a recent change in behavior--it seems that GDB is now trying > to insert the breakpoint when the user uses the 'break' command, > whereas it used to insert the breakpoint when GDB went to resume (or > start) execution. > I'll try to look at it this weekend, but it's looking busy. :-/ Does > this problem ring a bell with anyone who has been making changes > recently? Hm... are you sure this isn't older than the most recent sources? I have what may be related problems in gdb-4.18 as delivered with SuSE linux 6.2 (one similarity is that the shared command seems to do nothing): 1. individual source files in shared libraries are not known until you get to the main function (gdb) shared (gdb) break karbitraryxmlhandler.cpp:116 No source file named karbitraryxmlhandler.cpp. (gdb) break main Breakpoint 1 at 0x804e58b (gdb) r Starting program: /home/sb/2x/bin/metis Breakpoint 1, 0x804e58b in main () (gdb) break karbitraryxmlhandler.cpp:116 Breakpoint 2 at 0x410eccf0: file xml/karbitraryxmlhandler.cpp, line 116. (gdb) c Continuing. Qt: gdb: -nograb added to command-line options. Use the -dograb option to enforce grabbing. Breakpoint 2, KArbitraryXmlHandler::Rep::Rep (this=0x8289958, url=0x82fb050) at xml/karbitraryxmlhandler.cpp:116 Current language: auto; currently c++ (gdb) This behaviour has been there for a while. It was present in 4.17 as well. You either has to break on main or run the program through once to be allowed to set breakpoints in shared libs 2. the program being debugged, crashes if you try to start it with breakpoints in shared libs enabled: (gdb) r Starting program: /home/sb/2x/bin/metis /home/sb/2x/bin/metis: error in loading shared libraries: libmetis_kernel.so.1: failed to map segment from shared object: Cannot allocate memory Program exited with code 0177. (gdb) 3. If you disable the breakpoints, you will get warnings about gdb failing to reinsert the breakpoints automatically, and you will have to reenable them manually, after stopping in main(): (gdb) dis 2 (gdb) r Starting program: /home/sb/2x/bin/metis Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Error in re-setting breakpoint 2: No source file named karbitraryxmlhandler.cpp. Breakpoint 1, 0x804e58b in main () Current language: auto; currently c (gdb) ena 2 (gdb) c Continuing. Qt: gdb: -nograb added to command-line options. Use the -dograb option to enforce grabbing. Breakpoint 2, KArbitraryXmlHandler::Rep::Rep (this=0x8311c10, url=0x811b768) at xml/karbitraryxmlhandler.cpp:116 Current language: auto; currently c++ (gdb) This is inconvenient. In gdb-4.17 one could leave them enabled and gdb would disable them at startup, and reenable them after they became available Note that the program being debugged was a C++ program. >From davidwilliams@ozemail.com.au Sat Apr 01 00:00:00 2000 From: David Williams To: William Gatliff Cc: "gdb@sourceware.cygnus.com" Subject: Re: Breakpoints Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38711A49.C239221D@ozemail.com.au> References: <01BF4D1C.4AD8ABC0.davidwilliams@ozemail.com.au> <3870B8E0.B4BB4034@haulpak.com> X-SW-Source: 2000-q1/msg00002.html Content-length: 2119 I have seen gdb use breakpoints when steping at the source level. It mostly uses multiple 's' packets but occasionally uses a break point. Of course when stepping over a function (next) it always uses a breakpoint. No one has given me a definitive answer on this, but from my experience so far it would seem that gdb does not set multiple breakpoints when stepping (using either step or next). If anyone has had a different experience I would love to hear from you. Thanks David Williams davidwilliams@ozemail.com.au William Gatliff wrote: > Whenever I have seen gdb step through source, it always uses multiple 's' > packets--- it doesn't set breakpoints at all. > > b.g. > > David Williams wrote: > > > My question is still does GDB need to set more than one breakpoint when > > stepping through source? Thinking about it a little more GDB should have > > all of the information available to decide whether a branch will occur. It > > has the current value of all the registers (esp CCR) so it can work it out > > - the real question is does it use this information? > > > > Dave. > > > > ---------- > > From: Mark Salter[SMTP:msalter@cygnus.com] > > Sent: Thursday, December 23, 1999 2:09 AM > > To: kevinb@cygnus.com > > Cc: davidwilliams@ozemail.com.au; gdb@sourceware.cygnus.com > > Subject: Re: Breakpoints > > > > >>>>> Kevin Buettner writes: > > > > > On Dec 22, 2:29pm, David Williams wrote: > > >> Does GDB ever need to set more than one breakpoint when stepping through > > >> source code? I have not (as yet) seen this type of behaviour. > > > > > Can the target do a singlestep in hardware or do you have to do > > > software emulation? If the latter, when you're stepping by machine > > > instruction, you'd need two breakpoints on a conditional branch; > > > one for the branch target, the other for the instruction after the > > > branch. > > > > Even in the latter case, the stub can evaluate the condition of the > > branch to see which way its going to go. > > > > --Mark > > -- > William A. Gatliff > Senior Design Engineer > Komatsu Mining Systems > To teach is to learn. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Faylor To: Eli Zaretskii Cc: toddpw@windriver.com, gdb@sourceware.cygnus.com Subject: Re: Readline and -DMINIMAL Date: Fri, 31 Mar 2000 18:28:00 -0000 Message-ID: <20000331212807.A2696@cygnus.com> References: <200003281230.EAA15638@alabama.wrs.com> <20000328105123.G27306@cygnus.com> <200003312329.SAA07193@indy.delorie.com> X-SW-Source: 2000-03/msg00389.html Message-ID: <20000331182800.ElrLg8zJyogtgfdMgOADEKkcXUqimVz-jQVe5RM-GSA@z> On Fri, Mar 31, 2000 at 06:29:30PM -0500, Eli Zaretskii wrote: >> The readline directory in CVS is version >> 4.0 with changes from Eli Zaretskii (I hope he also notified the readline >> maintainer about these) to get things working on DJGPP. > >I checked my patches against the recent beta version of Readline, and >all the changes are already taken care of there (the person who ported >Bash to DJGPP submitted almost identical patches to the Readline >maintainer). That's good to hear. I guess we should think about importint the newest readline sometime after 5.0 branches. cgf >From cgf@cygnus.com Fri Mar 31 18:29:00 2000 From: Chris Faylor To: David Williams Cc: Serge Nikulin , gdb@sourceware.cygnus.com Subject: Re: How to set RS232 speed in gdb in WinNT? Date: Fri, 31 Mar 2000 18:29:00 -0000 Message-id: <20000331212950.B2696@cygnus.com> References: <003e01bf9b69$afc0c220$35758798@mis.amat.com> <38E538DF.ED6289D6@ozemail.com.au> X-SW-Source: 2000-03/msg00390.html Content-length: 1359 On Sat, Apr 01, 2000 at 09:46:40AM +1000, David Williams wrote: >Use -b command line option to change baud rate > >eg. gdb -b 115200 >to set baud rate 115200 baud. >Dave. Note that in some older versions of the Cygwin DLL (possibly in B20.1) there was an error which caused the 115200 baud rate to be incorrectly handled. Everything should work ok if you are using the Cygwin CD or if you are using a later cygwin snapshot. cgf >Serge Nikulin wrote: >> I use gdb for remote debugging of m68k target, compiled with MRI >> <--host=i686-pc-cygwin32 --target=m68k-motorola-ieee> >> Native MRI' X-Ray debugger does not support our home-made RTOS. >> GDB works but I have few questions. >> >> 1) Currently ieee-695 bfd section is not connected to gdb, so I work without >> src. >> I've checked examples of coff and aout conections and it does not look >> as a 1-day job for me >> (including the fact that ieee-695 support in bfd is incomplete). >> Does anyone have ieee + gdb experience? >> >> 2) In my gdb session under WinNT I use command "target remote com1" >> In this case gdb connects to COM1 at 9600 baud. I'd like to change this >> speed (say, to 38400) but I can't. I've changed default speed for COM1 in >> WinNT's control panel but it did not help. It looks like I have to pass that >> speed to cygwin.dll somehow. How can I do that? >From ac131313@cygnus.com Sat Apr 01 17:13:00 2000 From: Andrew Cagney To: GDB Discussion , GDB Patches Subject: GDB five branch - tuesday GMT? Date: Sat, 01 Apr 2000 17:13:00 -0000 Message-id: <38E69E5D.B67C1941@cygnus.com> X-SW-Source: 2000-04/msg00000.html Content-length: 199 [Reply-to: set to gdb-patches] Looking at what is still outstanding, and assuming I get back positive e-mails, I think it will be possible to cut the GDB 5 branch around Tuesday lunch GMT. Andrew >From Philip.Blundell@pobox.com Sun Apr 02 12:46:00 2000 From: Philip Blundell To: scottb@netwinder.org Cc: gdb@sourceware.cygnus.com Subject: gdb build fails for i586-linux cross arm-linux Date: Sun, 02 Apr 2000 12:46:00 -0000 Message-id: X-SW-Source: 2000-04/msg00001.html Content-length: 1144 Hi Scott Compiling the current GDB on my Intel machine with `--target=arm-linux', I get: gcc -g -o gdb main.o libgdb.a ../bfd/libbfd.a ../readline/libreadline.a ../opcodes/libopcodes.a ../libiberty/libiberty.a -lncurses ../libgui/src/libgui.a -L/var/tmp/build/binutils-arm/itcl/itcl/unix -litcl3.0 -L/var/tmp/build/binutils-arm/itcl/itk/unix -litk3.0 -L/var/tmp/build/binutils-arm/tix/unix/tk8.0 -ltix4.1.8.0 -L/var/tmp/build/binutils-arm/tk/unix -ltk8.0 -L/var/tmp/build/binutils-arm/tcl/unix -ltcl8.0 -L/usr/X11R6/lib -lX11 -ldl -lieee -lm -lm ../libiberty/libiberty.a -ldl -rdynamic libgdb.a(values.o): In function `value_being_returned': /usr/src/sourceware/src/gdb/values.c:1542: undefined reference to `arm_linux_extract_return_value' libgdb.a(infrun.o): In function `handle_inferior_event': /usr/src/sourceware/src/gdb/infrun.c:2296: undefined reference to `arm_get_longjmp_target' These functions are defined in arm-linux-nat.c but required by config/arm/tm-linux.h. Should we create a new arm-linux-tdep.c file for these functions, or are they genuinely not useful outside a native environment? Thanks p.