Re: annotate.texi

[Eli Zaretskii <eliz@delorie.com>]

> > Is there any reason why annotate.texi shouldn't be @include'd by
> > gdb.texinfo and be part of the manual?  Right now, "set annotate" is
> > not documented at all, and annotate.texi seems to be just what the
> > doctor ordered...
> 
> This is on my long-term wish list for the manual, along with agentexpr
> info.

So, will it be okay to submit a change to gdb.texinfo to include
annotate.texi (and add the appropriate menu items to gdb.texinfo)?
IMHO, no matter how incomplete annotate.texi might be, it is still
MUCH better than not telling anything about this feature.

> > And while at that, NEWS seems to be in the need of some work, it
> > doesn't mention many of the new features that already are in the CVS
> > tree.  I would like at least to mention the improvements in the DJGPP
> > version.
> 
> Yes please.

Will do.

> But seriously, everybody doing a checkin should ask themselves: will
> users want to know about this change?  Usually the answer will be
> yes; users complain about lack of information far more often than
> about overloaded...

The manual is also in dire need of more indexing.  I find myself using
(the inefficient) search command too much, instead of (the superb)
index-search.  Simple search is painful in a large manual.

I'm trying to add some indexing whenever I can.  But I suggest that
every manual patch be scrutinized for appropriate index entries, and
that this policy be published in the guidelines.
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches)
To: Jimmy Guo <guo@cup.hp.com>
Cc: "Daniel Berlin+list.gdb-patches" <dan@cgsoftware.com>, gdb@sourceware.cygnus.com, gcc@gcc.gnu.org
Subject: Re: C++ Overload testsuite fixes, need someone to verify
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <r9d1570b.fsf@dan.resnet.rochester.edu>
References: <Pine.LNX.4.10.10003232107500.12214-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-q1/msg00790.html
Content-length: 3446

Jimmy Guo <guo@cup.hp.com> writes:

It is a debug info problem.

GNU gdb 20000204
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsdelf4.0".
(gdb) file testsuite/gdb.c++/ovldbreak
Reading symbols from testsuite/gdb.c++/ovldbreak...done.
(gdb) b main
Breakpoint 1 at 0x804882f: file ./gdb.c++/ovldbreak.cc, line 48.
(gdb) bash-2.03#
bash-2.03# g++ -v
Using builtin specs.
gcc version 2.95.2 19991024 (release)


That's with STABS (or dwarf1, i forget the default, might be dwarf1).

bash-2.03# ./gdb -nw a.out
GNU gdb 20000204
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsdelf4.0"...
Setting up the environment for debugging gdb.
.gdbinit:5: Error in sourced command file:
Function "internal_error" not defined.
(gdb) b main
During symbol reading, type qualifier 'const' ignored.
Breakpoint 1 at 0x804883c: file testsuite/gdb.c++/ovldbreak.cc, line 49.
(gdb)

That's with DWARF2.


Can someone please grant me the sage wisdom about what to do about
this?

Modify the regexp to accept 48/49, or just pout in the corner and
live with the testsuite failures for now?


--Dan
> Might be.  I just checked sourceware 3/21's gdb built for
> hppa1.1-hp-hpux10.20, with ovldbreak.cc compiled by GNUPro g++, and it
> reports breakpoint on main at line 49.  This seem to point to the
> compiler rather than the debugger that you are using.
> 
> - Jimmy Guo, guo@cup.hp.com
> 
> >Jimmy Guo <guo@cup.hp.com> writes:
> >
> >the "{" is on line 48, the first line of the code ("char arg1") is at
> >49.
> >I smell a debugging info issue, where your compiler says it starts at
> >49, and mine says 48.
> >I think the real solution is to accept 48 and 49, but say anything
> >else is wrong.
> >Or fix gcc, if it's broken.
> >Something is telling me i remember seeing something about this problem
> >in gcc recently, something about where it's saying the first line of a
> >functions starts.
> >Can any of the GCC guys tell me if i'm making this up in my head (I
> >believe it was related to where it put the note about the function
> >start or something like that)?
> >--Dan
> >> >Can someone verify, that i am correct in thinking you get unexpected
> >> >failures in gdb.c++/ovldbreak.exp due to "breakpoint info" failures?
> >> >I have a patch, i just want to make sure it's not me.
> >> >It appears the source line the test suite expects main to appear on
> >> >in that file is 49, and main really appears at 48, so the regex to
> >> >match doesn't work.  I diffed the ovldbreak.cc file, and i get no
> >> >differences.
> >> 
> >> I think it should report 49, not 48.  Line 49 is the first executable
> >> statement of main.  I'm using the HP WDB source, in case you cannot see
> >> such behavior with sourceware's (in that case I will spend some time
> >> digging up the fix to submit as a patch).
> >> 
> >> - Jimmy Guo
From muller@cerbere.u-strasbg.fr Sat Apr 01 00:00:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Pascal language support patch preparation
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003021613.RAA03663@cerbere.u-strasbg.fr>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr>
X-SW-Source: 2000-q1/msg00509.html
Content-length: 3955

At 16:02 02/03/00 +0100, you wrote:
>   Date: Thu, 02 Mar 2000 15:16:19 +0100
>   From: Pierre Muller <muller@cerbere.u-strasbg.fr>
>
>   >Patches to create those new p-* files cannot be broken up of course,
>   >but your patch also touches a lot of the other GDB files.  Breaking
>   >those patches up in smaller though functionally related chunks makes
>   >reviewing and applying the patches a lot easier.
>   >
>   >I'd advise you to do the following:
>   >
>   >1. If you need some tweaks in GDB that do not depend on the Pascal
>   >   support itself, start submitting these ASAP.
>
>     I don't think I really have such code !
>
>Are you sure?  The patch I downloaded last fall includes changes to
>breakpoint.c, findvar.c, i387-tdep.c, infcmd.c and source.c that seem
>to be pretty independent of Pascal at first glance.
   Most are obsolete now !

>   >2. Then send the new p-* as one single patch.
>
>    Alone ? tihs would just leave them  unused first !
>
>That's not a problem.  The point is that these changes cannot break
>anything, so they don't need a lot of attention.
>
>   >3. Then send a patch that adds the code to hook in the GDB support.
>
>    OK, here a would have the biggest part of the problems probably
>   because some of the change are not trivial but I agree that I can probably
>   splitt those.
>
>That would indeed be best, since that lets the maintainer of that
>particular part of GDB deal with problems one at a time, which in
>general gets the changes integrated much quicker.
>

  This reminds me that I have one other patch which is quite smaller but
that is limited to DJGPP target for now.
 It allows to read memory from another selector
this was very usefull for me when I tried to debug the debugger itself and 
when I added exception support fro GDB on DJGPP !

This patch consists of the addition of one command that I called "xx"
which is a simple clone of the "x" command but can take a selector 
as for intance 
   "xx $fs:0x400"
then the next "xx 0x800" keeps using the last selector value.
I do not know if this could be interesting for other i386 targets
(maybe for win32 to be able to see the content of the $fs selector
that contains the exception chain, but I am not sure how if its
readable inside a win32 API program).
  Is such kind of patch too specific to have any chance to get accepted ?
I don't know if it could be of any use for other processors!!


>     For instance a big problem on which I spent a lot of time is to 
>   get GDB to accept the fact the pascal is case insensitive
>   this required changes in gnu-regex code !!
>
>I'm sorry to hear that you spent a lot of time on it.  Modifying the
>regex code is something that we should only do as a last resort since
>it is shared with a lot of other GNU packages.  Maybe GDB should use
>the POSIX functions instead of the BSD functions such that REG_ICASE
>can be used when the default language is Pascal.

  I would also prefer a simpler approach because that code
is quite ugly in my opinion!

>On the bright side: Case insensitivity would be convenient, but should
>not be essential for basic Pascal support in GDB.  We should be able
>to address this as a seperate issue.  I'll see what I can do.  For now
>it is probably better to leave out this bit when you send your new
>patches.

  Anyhow I agree that this can and should be done later.

>   >Yes it is, but it isn't the version that was used for reformatting the
>   >GDB sources.  See:
>   >
>   >   http://sourceware.cygnus.com/ml/gdb/1999-q3/msg00014.html
>
>    This not really very informative on the method that was used to do it !
>
>Pardon me?  It clearly states that:  ``[Stan] used indent 1.9.1 (with
>no arguments)''.
  Sorry, I didn't read the message carefully enough it seems :(



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: khendricks@ivey.uwo.ca
Cc: dan@cgsoftware.com, gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <ya8vapt7.fsf@dan.resnet.rochester.edu>
References: <950048577_PM_BeOS.dan@cgsoftware.com> <00020823060800.00592@localhost.localdomain>
X-SW-Source: 2000-q1/msg00187.html
Content-length: 4592

Kevin Hendricks <khendricks@ivey.uwo.ca> writes:

> Hi,
> 
> > What you are really saying is that it's better to put hacks and crap in 
> > the tree, and hope someone comes along and does it right, removing the 
> > hack, while making it even more a living hell for everyone else to 
> > understand.
> 
> Why is eveything "not perfect" considered a hack or crap?  I for one don't
> think Kevin Buettner's patch is a hack or crap at all. Please stop equating
> what we want to see added with crap.

We must have our wires crossed.
I wasn't referring to Kevin's patch when i said crap. Sorry for the
misunderstanding.

> 
> > See, here is your fatal mistake.
> > You are making the assumption that users will clean it up, make it work, 
> > and improve it.
> > While this may be true in other projects, it's not really true in GDB's 
> > case.
> 
> I think your attitude here is just wrong (and frankly part of the whole gdb
> problem).  You obviously think you have cornered the market on some unique
> programming skill. 
No, I've just had the unfortunate experience of seeming to be the only
one who hacks on gdb for my platform (notice i said nothing about
using, there are plenty of users), among with many other experiences,
and most of the people i know share these experiences (with their own
particular projects, mainly driver authors).

> This is simply not true.   Users can and will help.   I would
> help (I was part of Blackdown's jdk porting team until recent events forced me
> to move on), Franz would help (he is *the* gcc person for ppc and without his
> work with them we (ppc) would still be in the dark ages, Gary Thomas would help
> (he is really the father of the whole linux ppc movement and is single handedly
> responsible for much of the code that ppc uses), etc.  We just need something
> to start playing with.  As it stands, we can't even submit official bug
> reports.   

> 
> Please stop thinking that gdb is so complex that only a maintainer can help
> (seen the inside of many multi-threaded virtual machines latesly?). 
Strangely enough, I have, having done the original port of kaffe (No
WAT) to BeOS before the person who did it now. Not as hairy as sun's,
i would imagine (I've never looked at their code).
It seems only the maintainers want to help (ppc-linux people like you
excluded, sorry if i put you in the wrong platform group, it's late :P)


> Sure we
> won't be as good as you, we won't be as productive as you, but we (and others)
> really can help. I think we are proof of that.  Unfortunately when I submitted 
> the original ppc patch (based on Kevin Buettner work) back around 4.16 or
> earlier,  I just never dreamed it would take this long to get anything there
> done with it.  
> 
> Perhaps cygnus plays too large a role in tool development.  Perhaps open source
> tools should not be tied so closely to any one company.  Too many conflicts of
> interest?  Too many paying customers versus the rest of us?  I just don't know.
> 
> But whatever the outcome, please stop assuming that all "users" are
idiots. 
Never said that, never would.
Believe me, i'd be more than happy to be proven wrong, and to have
tons of users submit patches for all areas of GDB.
I'm just not holding my breath waiting for it to happen, no matter
what we do.
Yet I'm always hoping users will help.
But i guess i've just been involved in projects lately where they
don't. Fer instance, I've recently turned over maintenance of two drivers i wrote (both for
sound cards on BeOS.) because i simply don't have the time, and the
only reports i get are "this doesn't work on my computer", and when i
try to follow up, get nothing. It's not for lack of users, either. The
download stats show when i release a new version, it gets downloaded
~5000 times (Goes up a little with each release, new users i assume).
None were willing to help in any way, shape or form. 
Well, you get the idea, no point in me rambling on.
> This is simply not the case and results in much of the bad or negative
> "mindset" I have seen in the gdb lists and tried to point out to Stan.

Like i said, unfortunately, my viewpoint comes from too many
experiences lately telling me it's true. I'd be glad to be wrong about
this.
> 
> Thanks for responding to my post. 

And thank you for responding to mine.
>  I am not sure we will ever agree on how
> things should be done but we are talking about it which is more than has been
> done of late.

Right.
Hopefully this email won't get too screwed by my new mailer (And
hopefully i have all my gnus settings right)
> 
> Take care,
> 
> Kevin