headers
Daniel Jacobowitz | 1 Mar 2007 01:00

Re: gdb testsuite Makefile.in issue

On Wed, Feb 28, 2007 at 03:32:29PM -0800, Michael Snyder wrote:
> Folks, 
> 
> The following line has frequently caused me problems:
> 
>       t='$(program_transform_name)'; echo runtest | sed -e '' $$t; \
> 
> I think you do not run into it if you have dejagnu in your
> source tree, or if your host == target.  But if those conditions
> are not met, this line bombs.
> 
> My shell script foo is not strong, but I believe it should be
> "sed -e '$$t';", not "sed -e '' $$t'"
> 
> Yes?  No?

Why should it be any of those?  It's just runtest, not
$target-runtest.  The line gets overridden anyway if you run make
check up a directory, I imagine that's why I never see it.

Anyway, gcc uses:

AR_FOR_TARGET := $(shell \
  if [ -f $(objdir)/../binutils/ar ] ; then \
    echo $(objdir)/../binutils/ar ; \
  else \
    if [ "$(host)" = "$(target)" ] ; then \
      echo $(AR); \
    else \
       t='$(program_transform_name)'; echo ar | sed -e $$t ; \
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bill Baxter | 1 Mar 2007 01:00
Picon
Gravatar

Re: gdbmi.el not working with emacs 22

Thanks for the speedy reply, Nick.
Responses inline below:

On 3/1/07, Nick Roberts <nickrob <at> snap.net.nz> wrote:

> I'm glad to hear that this works with MinGW.
>
>  > However M-x gdbmi with the default command-line did not work
>  > properly.  It is able to debug, but the decorations don't show up in
>  > the margin.
>
> Emacs 22 has probably changed too much in CVS in that time.  It *should* work
> with latest GDB (6.6) but I don't know if MinGW has such a build.

No 6.2.3 is the latest snapshot.  So you suspect 6.2.3's MI output is
to old to work with the current emacs code?  I'm not sure what you
mean by Emacs 22 changing too much.  Does that mean my emacs is too
new or too old?  Or my gdb is too old or too new for it?

I'd like to try to help get it working by tinkering on the elisp side,
but some hints about what to look for would be nice.

>  > Is this a bug, or a known issue, or what?
>  > Should I file a bug report?
>
> Please don't file a bug report.  It does says in the file that it's under
> development, but perhaps it should carry a stronger health warning.

It says this:
;; This mode acts as a graphical user interface to GDB and works with Emacs
(Continue reading)

Permalink | Reply | 12 comments |
headers
Daniel Jacobowitz | 1 Mar 2007 01:05

Re: gdbmi.el not working with emacs 22

On Thu, Mar 01, 2007 at 09:00:46AM +0900, Bill Baxter wrote:
> >Emacs 22 has probably changed too much in CVS in that time.  It *should* 
> >work
> >with latest GDB (6.6) but I don't know if MinGW has such a build.
> 
> No 6.2.3 is the latest snapshot.  So you suspect 6.2.3's MI output is
> to old to work with the current emacs code?

What do you mean by 6.2.3?  Please see http://sourceware.org/gdb/ to
get a current release of GDB - I do not know of any with that version
number.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 9 comments |
headers
Bill Baxter | 1 Mar 2007 01:11
Picon
Gravatar

Re: gdbmi.el not working with emacs 22

On 3/1/07, Daniel Jacobowitz <drow <at> false.org> wrote:
> On Thu, Mar 01, 2007 at 09:00:46AM +0900, Bill Baxter wrote:
> > >Emacs 22 has probably changed too much in CVS in that time.  It *should*
> > >work
> > >with latest GDB (6.6) but I don't know if MinGW has such a build.
> >
> > No 6.2.3 is the latest snapshot.  So you suspect 6.2.3's MI output is
> > to old to work with the current emacs code?
>
> What do you mean by 6.2.3?  Please see http://sourceware.org/gdb/ to
> get a current release of GDB - I do not know of any with that version
> number.

Sorry I meant 6.3.2.

--bb
Permalink | Reply | 8 comments |
headers
Nick Roberts | 1 Mar 2007 01:31
Picon

Re: gdbmi.el not working with emacs 22

 > >  > However M-x gdbmi with the default command-line did not work
 > >  > properly.  It is able to debug, but the decorations don't show up in
 > >  > the margin.
 > >
 > > Emacs 22 has probably changed too much in CVS in that time.  It *should*
 > > work with latest GDB (6.6) but I don't know if MinGW has such a build.
 > 
 > No 6.2.3 is the latest snapshot.  So you suspect 6.2.3's MI output is
 > to old to work with the current emacs code?  

Yes.  MI is under development too, that's why I included gdb-mi.el in GDB
- to keep up with the changes.

 >                                              I'm not sure what you
 > mean by Emacs 22 changing too much.

Emacs 22 still hasn't officially been released although you may have got
a pretest tarball, or possibly a snapshot packaged for a ditribution such
as Debian. 

 > Does that mean my emacs is too
 > new or too old?  Or my gdb is too old or too new for it?

Probably just your gdb as your emacs is much more recent.

 >...
 > > Please don't file a bug report.  It does says in the file that it's under
 > > development, but perhaps it should carry a stronger health warning.
 > 
 > It says this:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 1 Mar 2007 01:32

Re: gdbmi.el not working with emacs 22

On Thu, Mar 01, 2007 at 09:11:47AM +0900, Bill Baxter wrote:
> On 3/1/07, Daniel Jacobowitz <drow <at> false.org> wrote:
> >On Thu, Mar 01, 2007 at 09:00:46AM +0900, Bill Baxter wrote:
> >> >Emacs 22 has probably changed too much in CVS in that time.  It *should*
> >> >work
> >> >with latest GDB (6.6) but I don't know if MinGW has such a build.
> >>
> >> No 6.2.3 is the latest snapshot.  So you suspect 6.2.3's MI output is
> >> to old to work with the current emacs code?
> >
> >What do you mean by 6.2.3?  Please see http://sourceware.org/gdb/ to
> >get a current release of GDB - I do not know of any with that version
> >number.
> 
> Sorry I meant 6.3.2.

Same problem, same advice.  The latest release of GDB is version 6.6.

I suspect you're looking at some older MinGW package.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 7 comments |
headers
Jim Blandy | 1 Mar 2007 01:43

Re: [RFC] Signed/unsigned character arrays are not strings


Daniel Jacobowitz <drow <at> false.org> writes:
> On Tue, Feb 27, 2007 at 11:11:32PM +0100, Mark Kettenis wrote:
>> Anyway, I'm in favour of restore the traditional gdb behaviour of
>> printing all three as strings.
>
> While I haven't seen responses to some of my arguments in favor of the
> new behavior, it's obvious that I'm in the minority here.  So, the
> behavior ought to change.
>
> I was concerned about Jim's patch, but thinking about it some more, I
> would be happy with it (probably with Paul's suggestion).  That's
> because "typedef char *name" is reasonably common, but "typedef char
> name_unit;" is much less so.  What do those who prefer the old
> behavior think of that?

For whatever it's worth, here's a revised patch that implements Paul's
suggestions and has better comments (more accurately apologetic):

gdb/ChangeLog:
2007-02-27  Jim Blandy  <jimb <at> codesourcery.com>

	* c-valprint.c (textual_element_type): New function.
	(c_val_print): Use textual_element_type to decide whether to print
	arrays, pointer types, and integer types as strings and characters.
	(c_value_print): Doc fix.

Index: gdb/c-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/c-valprint.c,v
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Roberts | 1 Mar 2007 01:54
Picon

Re: [RFC] Signed/unsigned character arrays are not strings

 > While I haven't seen responses to some of my arguments in favor of the
 > new behavior, it's obvious that I'm in the minority here.

Yes, but I think choices should be based on reason, not gut feeling.  The
change didn't receive much attention for a month, so it can't be that great a
problem.

 >...
 > By the way, I was thinking about this last night and wondered if
 > this is hinting at a sensible meaning for "print /s" ...

I like this approach because it's simple.  Jim's is too complicated (well,
for me, at least!).

--

-- 
Nick                                           http://www.inet.net.nz/~nickrob
Permalink | Reply | 0 comments |
headers
Bill Baxter | 1 Mar 2007 01:56
Picon
Gravatar

Re: gdbmi.el not working with emacs 22

On 3/1/07, Daniel Jacobowitz <drow <at> false.org> wrote:

> Same problem, same advice.  The latest release of GDB is version 6.6.
>
> I suspect you're looking at some older MinGW package.

No that's the latest MinGW has.  Unless you see something I don't at
their download pages:
  http://www.mingw.org/download.shtml
  http://sourceforge.net/project/showfiles.php?group_id=2435

They don't have any gcc based on gcc-4.x either.

But anyway, I have cygwin too, so if their stuff is more recent and
has a better chance of working I'll try that.  <checks>  actually
cygwin's version is 6.5.50.
    GNU gdb 6.5.50.20060706-cvs (cygwin-special)
So I guess that won't cut it either?
--bb

--bb
Permalink | Reply | 5 comments |
headers
Bill Baxter | 1 Mar 2007 02:09
Picon
Gravatar

Re: gdbmi.el not working with emacs 22

On 3/1/07, Bill Baxter <wbaxter <at> gmail.com> wrote:
> On 3/1/07, Daniel Jacobowitz <drow <at> false.org> wrote:
>
> > Same problem, same advice.  The latest release of GDB is version 6.6.
> >
> > I suspect you're looking at some older MinGW package.
>
> No that's the latest MinGW has.  Unless you see something I don't at
> their download pages:
>   http://www.mingw.org/download.shtml
>   http://sourceforge.net/project/showfiles.php?group_id=2435
>
> They don't have any gcc based on gcc-4.x either.
>
> But anyway, I have cygwin too, so if their stuff is more recent and
> has a better chance of working I'll try that.  <checks>  actually
> cygwin's version is 6.5.50.
>     GNU gdb 6.5.50.20060706-cvs (cygwin-special)
> So I guess that won't cut it either?

I gave it a shot.  Looks like that doesn't work either.
Break points show up, which is an improvement, but current-line
display doesn't work.
Oh well.  I'll try again some day after Emacs 22 is official and gdb
6.6 is in cygwin.

Thanks for your help.
--bb
(Continue reading)

Permalink | Reply | 4 comments |

Gmane