Re: Readline and -DMINIMAL

Re: Readline and -DMINIMAL

[Chris Faylor]

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 <cgf@cygnus.com>
To: David Williams <davidwilliams@ozemail.com.au>
Cc: Serge Nikulin <nikulin@actsw.amat.com>, 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 <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
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 <Philip.Blundell@pobox.com>
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: <E12bqKZ-0005uP-00@kings-cross.london.uk.eu.org>
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.

Re: Readline and -DMINIMAL

[Chris Faylor]

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 <sb@metis.no>
To: Jason Molenda <jsm@cygnus.com>
Cc: Bryce McKinlay <bryce@albatross.co.nz>, Takis Psarogiannakopoulos <takis@XFree86.org>, gdb@sourceware.cygnus.com
Subject: Re: SHARED LIBS
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <wh66x0kifz.fsf@viffer.metis.no>
References: <Pine.BSF.4.05.9912171549080.11097-200000@public.xfree86.org> <385AF8A8.95EF6BD4@albatross.co.nz> <whaemckir8.fsf@totally-fudged-out-message-id>
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 <davidwilliams@ozemail.com.au>
To: William Gatliff <gatliff@haulpak.com>
Cc: "gdb@sourceware.cygnus.com" <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.