* Re: Readline and -DMINIMAL
[not found] ` <200003312329.SAA07193@indy.delorie.com>
@ 2000-04-01 0:00 ` Chris Faylor
2000-03-31 18:28 ` Chris Faylor
0 siblings, 1 reply; 2+ messages in thread
From: Chris Faylor @ 2000-04-01 0:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: toddpw, gdb
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.
^ permalink raw reply [flat|nested] 2+ messages in thread