headers
Bob Rossi | 1 Jul 2005 02:20

Re: [PATCH] Hooks still needed for annotations

> > Also, I think it's reasonable to say that GDB should have a parser that
> > FE's can use. The only way to have a parser that can be tested properly
> > is to allow it to be packaged and tested in GDB's testsuite. Otherwise,
> > if the annotations are removed, FE's like GVD, XXGDB, DDD, KGDB, ...
> > are either going to "go the way of the bison" or they are going to have
> > to write code that handles GDB/MI. Do we really want 5-10 GDB/MI
> > parser's out there (each with there own bugs)?
> 
> This is also unrelated to the removal of annotations.
> 
> I don't much think a parser is GDB's responsibility.  Offering one as a
> convenience, sure, maybe.  Note that a lot of frontends won't get to
> use it anyway!  If we ship it with GDB, then it's going to be covered
> under the GPL.

The more I think of it, the more I feel that I am correct on this. Even
if the parser was under the GPL, proprietary projects (Apple?) could
simply use the parse tree to translate the data into a nice format of
there own (XML?) and then communicate that to a parser thats linked into
there application. This type of solution would allow a closed source
company to get the benefits of an MI parser/semantical analyzer,
contribute to the project, and not have to think 1 second about low
level MI stuff in there FE.

Bob Rossi
Permalink | Reply | 1 comment |
headers
Nick Roberts | 1 Jul 2005 03:19
Picon

Re: [PATCH] Hooks still needed for annotations

Bob Rossi writes:
 > > I don't much think a parser is GDB's responsibility.  Offering one as a
 > > convenience, sure, maybe.  Note that a lot of frontends won't get to
 > > use it anyway!  If we ship it with GDB, then it's going to be covered
 > > under the GPL.
 > 
 > The more I think of it, the more I feel that I am correct on this. Even
 > if the parser was under the GPL, proprietary projects (Apple?) could
 > simply use the parse tree to translate the data into a nice format of
 > there own (XML?) and then communicate that to a parser thats linked into
 > there application. This type of solution would allow a closed source
 > company to get the benefits of an MI parser/semantical analyzer,
 > contribute to the project, and not have to think 1 second about low
 > level MI stuff in there FE.

Bob,

You're quoting Daniel (I think), not me.  I must say though, that I don't see
an immediate need for a parser.  We can dictate the MI output.  Why not just
get that to play nice?

Nick
Permalink | Reply | 0 comments |
headers
Nick Roberts | 1 Jul 2005 06:32
Picon

Re: PATCH: Start Fortran support for variable objects.

 > I have two comments below, hope that they might be helpful.  Thanks.
 > 
 > On Fri, 1 Jul 2005, Nick Roberts wrote:
 > 
 > > As in the patch below?  I don't understand the extra cases it appears to
 > > cover, but it worked for the tests I tried.
 > 
 > Maybe it is also helpful to test against such arrays definition as:
 >   
 >   integer array(0:5), integer array(-1:4)
 > 
 > or even
 >   
 >   integer array(0:5,-1:4)
 >
 > (if variable object does support multi-dimension array. I don't know much 
 > about variable object, and MI as a whole.)

Ah!  I see now.  I've not used such arrays in Fortran.  Using

      INTEGER ARRAY1(0:5), ARRAY2(-1:4)
      INTEGER ARRAY3(0:2,-1:1)
      DATA ARRAY1/1,2,3,4,5,6/
      DATA ARRAY2/1,2,3,4,5,6/
      DATA ARRAY3/11,21,31,12,22,32,13,23,33/

the latest patch seems to work (see attached image below).  I am sure
that my original patch would have failed for these cases.

 > The second comment is about the following text in a former mail Nick sent:
(Continue reading)

Permalink | Reply | 15 comments |
headers
Mark Kettenis | 1 Jul 2005 17:12
Picon

[commit] Add missing include to solib-svr4.c

Most targets still get it from "tm.h", but a few targets don't.

Committed as obvious.

Mark

2005-07-01  Mark Kettenis  <kettenis <at> gnu.org>

	* solib-svr4.c: Include "solib.h".
	* Makefile.in (solib-svr4.o): Update dependencies.

Index: solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.51
diff -u -p -r1.51 solib-svr4.c
--- solib-svr4.c	13 Jun 2005 18:39:11 -0000	1.51
+++ solib-svr4.c	1 Jul 2005 15:08:57 -0000
 <at>  <at>  -38,6 +38,7  <at>  <at> 
 #include "gdb_assert.h"

 #include "solist.h"
+#include "solib.h"
 #include "solib-svr4.h"

 #include "bfd-target.h"
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.738
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Ellcey | 1 Jul 2005 18:48
Picon

Patch to replace BFD_NEED_DECLARATION with AC_CHECK_DECLS

This patch removes the use of BFD_NEED_DECLARATION from gdb/gdbserver
and replaces it with AC_CHECK_DECLS.  Once this checkin is done I intend
to remove the definition of BFD_NEED_DECLARATION from the bfd
subdirectory as it is no longer needed now that we are using newer
versions of autoconf that have AC_CHECK_DECLS.

There is still a use of BFD_NEED_DECLARATION in src/mmalloc but my
understanding is that mmalloc is no longer used and so that use can be
ignored.

The change was tested on IA64 Linux with no regressions.  I have not
done any gdb checkins before but I have done binutils changes and I do
have a gdb copyright assignment on file and write access to the src
repository so I can check this in myself if it is approved.

OK to checkin?

Steve Ellcey
sje <at> cup.hp.com

src/gdb/gdbserver/ChangeLog

2005-07-01  Steve Ellcey  <sje <at> cup.hp.com>

	* configure.ac (BFD_NEED_DECLARATION): Replace with AC_CHECK_DECLS.
	* configure: Regenerate.
	* config.in: Regenerate.
	* server.h (NEED_DECLARATION_STRERROR):
	Replace with !HAVE_DECL_STRERROR.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 1 Jul 2005 18:54

Re: Patch to replace BFD_NEED_DECLARATION with AC_CHECK_DECLS

On Fri, Jul 01, 2005 at 09:48:56AM -0700, Steve Ellcey wrote:
> This patch removes the use of BFD_NEED_DECLARATION from gdb/gdbserver
> and replaces it with AC_CHECK_DECLS.  Once this checkin is done I intend
> to remove the definition of BFD_NEED_DECLARATION from the bfd
> subdirectory as it is no longer needed now that we are using newer
> versions of autoconf that have AC_CHECK_DECLS.
> 
> There is still a use of BFD_NEED_DECLARATION in src/mmalloc but my
> understanding is that mmalloc is no longer used and so that use can be
> ignored.
> 
> The change was tested on IA64 Linux with no regressions.  I have not
> done any gdb checkins before but I have done binutils changes and I do
> have a gdb copyright assignment on file and write access to the src
> repository so I can check this in myself if it is approved.
> 
> OK to checkin?

OK.  Please list yourself in write-after-approval in gdb/MAINTAINERS,
also.

--

-- 
Daniel Jacobowitz
CodeSourcery, LLC
Permalink | Reply | 0 comments |
headers
Nathan J. Williams | 1 Jul 2005 21:42
Picon
Favicon

[RFA/doc] GDB remote target waits for a response when detaching.


The documentation of the remote protocol says:

   GDB does not check for any response after sending this packet

but this isn't true. remote_detach() calls remote_send(), which calls
getpkt() and signals an error if the result starts with 'E'. This
seems to have been true "forever", or at least back to the beginning
of CVS.

OK to commit this doc change?

        - Nathan

	* gdb.texinfo (Packets): Change description of 'D' packet to
	note that GDB does wait for a response.

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.271
diff -u -r1.271 gdb.texinfo
--- gdb.texinfo	22 Jun 2005 06:20:00 -0000	1.271
+++ gdb.texinfo	1 Jul 2005 19:36:46 -0000
 <at>  <at>  -22058,8 +22058,10  <at>  <at> 

 Reply:
  <at> table  <at> samp
- <at> item  <at> emph{no response}
- <at> value{GDBN} does not check for any response after sending this packet.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eli Zaretskii | 1 Jul 2005 23:15
Picon

Re: [RFA/doc] GDB remote target waits for a response when detaching.

> From: nathanw <at> MIT.EDU (Nathan J. Williams)
> Date: 01 Jul 2005 15:42:06 -0400
> 
> The documentation of the remote protocol says:
> 
>    GDB does not check for any response after sending this packet
> 
> but this isn't true. remote_detach() calls remote_send(), which calls
> getpkt() and signals an error if the result starts with 'E'. This
> seems to have been true "forever", or at least back to the beginning
> of CVS.
> 
> OK to commit this doc change?

Yes, thanks.
Permalink | Reply | 0 comments |
headers
Steve Ellcey | 2 Jul 2005 01:10
Picon

Patch for gdb/configure cleanup (autoheader warnings)


While working on some configure changes I noticed that if you run
autoheader 2.59 in the src/gdb directory you get a bunch of warnings.
One warning is about using acconfig.h, which it says is depreciated, and
the others are about missing arguments to AC_DEFINE.  Since src/gdb now
requires autoconf/autoheader 2.59 or greater, I thought I would clean up
the configure.ac script to get rid of the warnings.

Comparing config.in before and after, there are a couple of differences.
HAVE_CATGETS was in the old config.in but not the new one.  Since I see
no use of this macro, I think this is OK.  _KMEMUSER is handled a bit
differently, now it just has an undef, before it was an undef inside an
ifndef/endif.  This didn't seem to cause any problems for me.
_GNU_SOURCE and _ALL_SOURCE were the same way.  Also, acinclude.m4 had a
definition for AC_GNU_SOURCE but that is now standard so I removed it.

There was also an undef of TUI in the old config.in, but there was no
corresponding AC_DEFINE for it and it looks like this is now passed in
as an argument so I didn't create an AC_DEFINE for it.  I tested TUI
mode on my machine and it did come up.

Part of this patch is to remove the file acconfig.h.  If there is
something more than 'cvs remove' that needs to be done when removing a
file I would like to know so that I don't do something bad.  I don't
think we can just leave the file behind because if we do autoconf will
continue to look at it and issue warnings.

The changes were tested on IA64 Linux with no regressions.

OK for checkin?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Daniel Jacobowitz | 2 Jul 2005 03:39

Re: Patch for gdb/configure cleanup (autoheader warnings)

On Fri, Jul 01, 2005 at 04:10:14PM -0700, Steve Ellcey wrote:
> Part of this patch is to remove the file acconfig.h.  If there is
> something more than 'cvs remove' that needs to be done when removing a
> file I would like to know so that I don't do something bad.  I don't
> think we can just leave the file behind because if we do autoconf will
> continue to look at it and issue warnings.

That's enough.

> OK for checkin?
> 
> 
> gdb/ChangeLog
> 
> 2005-07-01  Steve Ellcey  <sje <at> cup.hp.com>
> 
> 	* configure.ac:
> 	* acconfig.h: Remove file.
> 	* acinclude.m4 (AC_GNU_SOURCE): Remove definition.
> 	* configure: Regenerate.
> 	* config.in: Regenerate.

You've lost half your changelog entry :-)

Also, I notice you're converting XM_FILE.  It's dead; there are no sets
of it any more.  Someone should go through and purge the remaining bits
of it soon...

--

-- 
Daniel Jacobowitz
(Continue reading)

Permalink | Reply | 2 comments |

Gmane