Thread: Re: [bob@brasko.net: Re: [Cgdb-devel] cgdb on GNU/kFreeBSD]
Brought to you by:
bobbybrasko,
crouchingturbo
|
From: Bob R. <bo...@br...> - 2005-04-01 14:55:43
|
> i do have a few things (all in debian's cvs):
> - please update the config.guess and config.sub files to current
> versions, this would allow to build your package on may more systems,
> including the hurd!
OK, I'll look into how to do this, although I have no idea. This is
what I run to produce all the auto files,
rm -rf autom4te.cache/
aclocal -I config
autoconf
autoheader
automake -a
I'll look and see if I just need to update either autoconf or something
...
> - there is the old problem of segfaults on tsartup when ~/.tgdb isn't
> writeable. the problem itself isn't really important, but when
> investigating it and trying to build a patch i noticed that the error
> reporting involved is a bit weird. might be wrong, but you should have
> a look when you have time.
Yeah, I'm not terribly proud of the code in this application. By the
time 1.0 hits, most of it will be re-written. I'll look into fixing at
least this problem.
> - and there is a new problem (#296770) that i have to admit i didn't
> have the time to look into yet. the reporter says that when you
> recompile your program, cgdb doesn't reload the symbols.
Yeah, I mean, this has nothing to do with CGDB. GDB is responsible for
all the symbol loading. However, if the user is saying that CGDB
displays the old "source code" in the source viewer than that could be a
problem. I've added 2 new features in this release.
Problem is, the interface I have with GDB is not good enough to tell me
when a source file has been changed (because recompiled). So, I have no
way of knowing when to fetch the new file, instead of looking at the one
that was used when CGDB first needed the file.
So, I added the :edit [:e] feature, which allows you to reload the
current file you are looking at.
Also, I added the autosourcereload feature, here is the info from the
README
:set autosourcereload ->
If this is on, CGDB will automatically reload a
source file if it has changed since CGDB has opened it.
If it is off, the file will never be reloaded, until you
start CGDB again. The default is off. (:set asr)
This feature is useful when you are debugging a program,
then you modify a source file, recompile, and 'r' in
GDB's CLI window. The file in this case will be updated
to show the new version.
Note, CGDB only looks at the timestamp of the source file to
determine if it has changed. So if you modify the source file,
and didn't recompile yet, CGDB will still pick up on the changes.
> do you have any plans on when you want to release the next version? i'm
> asking because the sarge freeze is quite imminent now... (for real!)
I'd like to release as soon as possible. There have been many many bug
fixes since the last release, and CGDB should be much more stable for
people.
Thanks,
Bob Rossi
|
|
From: Bob R. <bo...@br...> - 2005-04-01 16:02:48
|
On Fri, Apr 01, 2005 at 10:54:13AM -0500, Bob Rossi wrote: > > i do have a few things (all in debian's cvs): > > - please update the config.guess and config.sub files to current > > versions, this would allow to build your package on may more systems, > > including the hurd! >=20 > OK, I'll look into how to do this, although I have no idea. This is > what I run to produce all the auto files, > rm -rf autom4te.cache/ >=20 > aclocal -I config > autoconf > autoheader > automake -a >=20 > I'll look and see if I just need to update either autoconf or something > ... Done. > > - there is the old problem of segfaults on tsartup when ~/.tgdb isn't > > writeable. the problem itself isn't really important, but when > > investigating it and trying to build a patch i noticed that the error > > reporting involved is a bit weird. might be wrong, but you should have > > a look when you have time. >=20 > Yeah, I'm not terribly proud of the code in this application. By the > time 1.0 hits, most of it will be re-written. I'll look into fixing at > least this problem. Is this good enough? $ ./cgdb/src/cgdb Error: Could not open file /home/bob/.tgdb/tgdb_log.txt for writing Error: Could not open log file Could not initialize logger interface cgdb.c:662 Unable to invoke GDBbob@black ~/cvs/cgdb/cgdb > > - and there is a new problem (#296770) that i have to admit i didn't > > have the time to look into yet. the reporter says that when you > > recompile your program, cgdb doesn't reload the symbols. >=20 > Yeah, I mean, this has nothing to do with CGDB. GDB is responsible for > all the symbol loading. However, if the user is saying that CGDB > displays the old "source code" in the source viewer than that could be a > problem. I've added 2 new features in this release. >=20 > Problem is, the interface I have with GDB is not good enough to tell me > when a source file has been changed (because recompiled). So, I have no > way of knowing when to fetch the new file, instead of looking at the one > that was used when CGDB first needed the file. >=20 > So, I added the :edit [:e] feature, which allows you to reload the > current file you are looking at. >=20 > Also, I added the autosourcereload feature, here is the info from the > README >=20 > :set autosourcereload ->=20 > If this is on, CGDB will automatically reload a > source file if it has changed since CGDB has opened it. > If it is off, the file will never be reloaded, until you > start CGDB again. The default is off. (:set asr) > This feature is useful when you are debugging a program, > then you modify a source file, recompile, and 'r' in > GDB's CLI window. The file in this case will be updated > to show the new version. > Note, CGDB only looks at the timestamp of the source file to > determine if it has changed. So if you modify the source file, > and didn't recompile yet, CGDB will still pick up on the changes. And will this solve the last problem? This might be enough to solve all the debian bug reports. Please let me know. Bob Rossi |