Re: GDB on Mac is (NOT) Broken

Re: GDB on Mac is (NOT) Broken

[Nick Roberts]

> I just compiled 23.1.94 on OSX leopard with-x and it freezes in
> following these simple steps:

> 1. M-x gdb
> 2. att TAB

> Any fix to get this working?

Yes, you could use non-proprietary software.  You could also try reading the
archives before posting.

You don't say what version of GDB you're using but I suspect it is Apple GDB.
If so, why not send a bug report to them explaining that their software is
broken because it doesn't work with Emacs?

-- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: GDB on Mac is (NOT) Broken

[Harald Hanche-Olsen]

+ nickrob@snap.net.nz (Nick Roberts):

> Yes, you could use non-proprietary software. [...]
> 
> You don't say what version of GDB you're using but I suspect it is Apple GDB.

Which, being GDB, is of course non-proprietary software (though it
runs on a proprietary platform), so Apple must, and does, provide a
copy of the modified source code. Many versions are here:

  http://www.opensource.apple.com/source/gdb/

They don't seem to provide the source in a handy archive format (does
the GPL require that?), but I expect that a suitably crafted wget
command will get you the whole tree.

- Harald

Re: GDB on Mac is (NOT) Broken

[Steve Revilak]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

>> I just compiled 23.1.94 on OSX leopard with-x and it freezes in
>> following these simple steps:

>> 1. M-x gdb
>> 2. att TAB

I reported this problem in 
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5404>.  Nick Roberts was
kind enough to guide me through some diagnostic exercies.  Perhaps
our most interesting finding was message 34.

    http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5404#34

The hang appears to be (at least somewhat) related to the onlcr tty
setting for the gdb subprocess.  And there may be some overlap with
the EOL conversions that YAMAMOTO Mitsuharu noted.

The workaround I've been using on Mac OS X is

    Within the *gud-PROGRAM* buffer, run "shell stty -onlcr" after the
    target program starts running, and don't try to use symbol
    completion before the target program starts.

The GDB is Apple's GDB.

I tend to move around between two Mac OS systems, and two GNU/Linux
systems.  5404's behavior is reliably reproducible on Mac OS X 10.4
and 10.6 with Apple's GDB.  I've never seen 5404's symptoms occur on
GNU/Linux.  I don't know whether 5404's behavior appears on Windows.

Finally, I haven't had a chance to compile 23.1.94 yet (still using
23.1.93).  So I can't say if any of 5404's behavior no longer applies
to 23.1.94.

Steve


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: GDB on Mac is (NOT) Broken

[Nick Roberts]

> > You don't say what version of GDB you're using but I suspect it is Apple GDB.

> Which, being GDB, is of course non-proprietary software (though it
> runs on a proprietary platform), so Apple must, and does, provide a
> copy of the modified source code. Many versions are here: ...

Yes, but last time I checked FSF GDB compiled and ran on Darwin, and hence MAC
OSX, and this version didn't have the problem with extra ^M characters.

Furthermore, Apple GDB is a branch of FSF GDB which, not unreasonably, has
been tailored to Apple requirements such as Xcode and AFAIK only compiles on
Mac OSX and related platforms (iPhone?).  GPL allows them to take changes from
FSF GDB but doesn't require them to push them back although others, myself
included, can and do.

That's whay, as I've said before:

That it [Emacs] doesn't work with Apple GDB I don't see as a bug.  Of course, if
you or someone else posts a fix, I will be happy to apply it.

- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: GDB on Mac is (NOT) Broken

[Chad Brown]

On Mar 14, 2010, at 11:23 PM, Nick Roberts wrote:

> [...]
> That it [Emacs] doesn't work with Apple GDB I don't see as a bug.  

Any idea why/how M-x gdb got into such a state that core emacs developers are saying things like ``it's such a complete mess that reporting all the bugs is a depressingly huge job''?   I have easy access to a macosx machine with gdb; maybe I can help.

Thanks in advance,
*Chad

Re: GDB on Mac is (NOT) Broken

[Nick Roberts]

 > Any idea why/how M-x gdb got into such a state that core emacs developers
 > are saying things like ``it's such a complete mess that reporting all the
 > bugs is a depressingly huge job''?  I have easy access to a macosx machine
 > with gdb; maybe I can help.

It's just Miles, I think, and I've no idea why he would choose to make such
remarks.  Perhaps you should ask him.  I don't think they are directed at the
Mac platform but, sure, any help will be gratefully received.

There are many people who like the "gdb-ui thingy" but perhaps they are not as
vocal as those who become unstuck.  However, I can make some suggestions that
could make the use of GDB in Emacs easier:

1) Read the documentation in the Emacs manual (M-x gud-gdb is described on the
eighth line of "Starting GUD".)

2) If you want to use GDB in Emacs in earnest, use a *released* version of
Emacs.

3) If you want to help with the development of GDB in Emacs, use the CVS
version of Emacs.

4) For a while the CVS version of Emacs used an interface called GDB/MI.  This
gave less reliable behaviour but is still a long term goal.  That may have
caused some frustration.

5) If you try, I'm sure you can get the GDB Graphical Interface to do the
wrong thing, like display the source in the wrong buffer, or worse.  Emacs is
so customisable/flexible that it's hard to do the right things in all cases.
It works fine for me when I'm careful about window configuration.  I use
'gdb-restore-windows' quite often.

6) Many poeple appear to use gdb-many-windows but I prefer not to and start
just with the GUD buffer.  The source appears when I hit a breakpoint and
I then just display the associated buffers, e.g., stack buffer, that I need in
a separate frame (from the menu-bar).

7) M-x gud-gdb is more reliable because it's more basic.  You get to see the
source but not much more.  You even have to remember where the breakpoints are.

I hope these comments are more helpful than some of the recent ones.  Please
do make bug reports but they need to be concise and provide a recipe to
reproduce the problem (see "Reporting Bugs" in the Emacs manual).

-- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: GDB on Mac is (NOT) Broken

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 15 Mar 2010 19:23:44 +1300, nickrob@snap.net.nz (Nick Roberts) said:

> That it [Emacs] doesn't work with Apple GDB I don't see as a bug.
> Of course, if you or someone else posts a fix, I will be happy to
> apply it.

The simplest workaround would be something like (push '("\\`gdb\\'"
. (utf-8-dos . utf-8-unix)) process-coding-system-alist).  But
detecting Apple versions of GDB would be better.  Could you check the
patch below?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

=== modified file 'lisp/progmodes/gdb-ui.el'
*** lisp/progmodes/gdb-ui.el	2010-02-19 04:55:31 +0000
--- lisp/progmodes/gdb-ui.el	2010-03-15 23:47:49 +0000
***************
*** 162,167 ****
--- 162,168 ----
  (defvar gdb-ready nil)
  (defvar gdb-stack-update nil)
  (defvar gdb-early-user-input nil)
+ (defvar gdb-first-output-line "")
  
  (defvar gdb-buffer-type nil
    "One of the symbols bound in `gdb-buffer-rules'.")
***************
*** 335,340 ****
--- 336,342 ----
    (setq gdb-stack-update nil)
    (setq gdb-flush-pending-output nil)
    (setq gdb-early-user-input nil)
+   (setq gdb-first-output-line "")
    (setq gud-filter-pending-text nil)
    (gdb-thread-identification)
    (run-hooks 'gdb-mode-hook))
***************
*** 705,710 ****
--- 707,722 ----
  
    (if gdb-use-separate-io-buffer (gdb-clear-inferior-io))
  
+   ;; Workaround for some Apple versions of GDB that add ^M at EOL
+   ;; after the command "server interpreter mi -stack-info-frame".
+   (if (string-match "(Apple version " gdb-first-output-line)
+       (let* ((process (get-buffer-process gud-comint-buffer))
+ 	     (coding-systems (process-coding-system process)))
+ 	(set-process-coding-system process
+ 				   (coding-system-change-eol-conversion
+ 				    (car coding-systems) 'dos)
+ 				   (cdr coding-systems))))
+ 
    ;; Hack to see test for GDB 6.4+ (-stack-info-frame was implemented in 6.4)
    (gdb-enqueue-input (list "server interpreter mi -stack-info-frame\n"
  			   'gdb-get-version)))
***************
*** 1769,1774 ****
--- 1781,1792 ----
  	(progn
  	  (setq output (gdb-concat-output output gud-marker-acc))
  	  (setq gud-marker-acc "")))
+       (if (not (string-match "\n" gdb-first-output-line))
+ 	  (setq gdb-first-output-line
+ 		(concat gdb-first-output-line
+ 			(if (string-match "\n" output)
+ 			    (substring output 0 (match-end 0))
+ 			  output))))
        output)))
  
  (defun gdb-concat-output (so-far new)

Re: GDB on Mac is (NOT) Broken

[Steve Revilak]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]


>>>>>> On Mon, 15 Mar 2010 19:23:44 +1300, nickrob@snap.net.nz (Nick Roberts) said:

>> That it [Emacs] doesn't work with Apple GDB I don't see as a bug.
>> Of course, if you or someone else posts a fix, I will be happy to
>> apply it.

>From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>

>The simplest workaround would be something like (push '("\\`gdb\\'"
>. (utf-8-dos . utf-8-unix)) process-coding-system-alist).  But
>detecting Apple versions of GDB would be better.  Could you check the
>patch below?

YAMAMOTO,

I would be happy to test your patch, but it will be a few days before
I have the opportunity to do so.  (I live in an area of Massachusetts
that was affected by flooding, and life is an unusual mix of priorties
right now :(

I'll report back when I can.

Steve Revilak


>=== modified file 'lisp/progmodes/gdb-ui.el'
>*** lisp/progmodes/gdb-ui.el	2010-02-19 04:55:31 +0000
>--- lisp/progmodes/gdb-ui.el	2010-03-15 23:47:49 +0000
    [...]

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: GDB on Mac is (NOT) Broken

[Nick Roberts]

 > The simplest workaround would be something like (push '("\\`gdb\\'"
 > . (utf-8-dos . utf-8-unix)) process-coding-system-alist).  But
 > detecting Apple versions of GDB would be better.  Could you check the
 > patch below?

I can only currently try it on GNU/Linux and I can confirm that it doesn't
break behaviour there.

Maybe Chad Brown or Leo could test it on a Mac.  I suspect that FSF GDB on
Mac would still also work but it would be good to check this too.

If there are no problems then please commit this change.

-- 
Nick                                           http://users.snap.net.nz/~nickrob


 > ***************
 > *** 1769,1774 ****
 > --- 1781,1792 ----
 >   	(progn
 >   	  (setq output (gdb-concat-output output gud-marker-acc))
 >   	  (setq gud-marker-acc "")))
 > +       (if (not (string-match "\n" gdb-first-output-line))

           (if (gdb-first-post-prompt)

would probably also work

 > + 	  (setq gdb-first-output-line
 > + 		(concat gdb-first-output-line
 > + 			(if (string-match "\n" output)
 > + 			    (substring output 0 (match-end 0))
 > + 			  output))))
 >         output)))
 >   
 >   (defun gdb-concat-output (so-far new)
 > 

Re: GDB on Mac is (NOT) Broken

[Chad Brown]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

On Mar 15, 2010, at 10:27 PM, Nick Roberts wrote:

>>   Could you check the patch below?
> 
> I can only currently try it on GNU/Linux and I can confirm that it doesn't
> break behaviour there.
> 
> Maybe Chad Brown or Leo could test it on a Mac.  I suspect that FSF GDB on
> Mac would still also work but it would be good to check this too.
> 
> If there are no problems then please commit this change.

I was able to test it against a pretty recent bazaar checkout (99384) and it works.  Would you like me to pull down the pretest and check against it?
*Chad

[-- Attachment #2: Type: text/html, Size: 1000 bytes --]

Re: GDB on Mac is (NOT) Broken

[Nick Roberts]

 > > Maybe Chad Brown or Leo could test it on a Mac.  I suspect that FSF GDB on
 > > Mac would still also work but it would be good to check this too.
 > > 
 > > If there are no problems then please commit this change.
 > 
 > I was able to test it against a pretty recent bazaar checkout (99384) and
 > it works.  Would you like me to pull down the pretest and check against it?

There appears to be only one unrelated change after 99384.  Did you test it
with FSF GDB too?

If you wish to help with development of GDB in Emacs in the longer term, you
would need the latest FSF GDB from the CVS repository at sourceware and the
latest Emacs from the savannah, as well as a Mac and Apple GDB to test it on
this platform.

-- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: GDB on Mac is (NOT) Broken

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 16 Mar 2010 18:27:03 +1300, nickrob@snap.net.nz (Nick Roberts) said:

>> ***************
>> *** 1769,1774 ****
>> --- 1781,1792 ----
>> (progn
>> (setq output (gdb-concat-output output gud-marker-acc))
>> (setq gud-marker-acc "")))
>> +       (if (not (string-match "\n" gdb-first-output-line))

>            (if (gdb-first-post-prompt)

> would probably also work

I guess you meant "(if gdb-first-prompt", but whichever the variables,
I think its value might be changed in the while-loop in
gud-gdba-marker-filter via annotation handler calls.  If we want to
avoid string-match for most cases, then we can save the original value
at the beginning of the while-loop to some variable (say,
orig-gdb-first-prompt) and use it like this:

  (if (and orig-gdb-first-prompt
           (not (string-match "\n" gdb-first-output-line)))

but it looks too much to me.

BTW, which branch should the patch go to, emacs-23 or trunk?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: GDB on Mac is (NOT) Broken

[Nick Roberts]

 > >> ***************
 > >> *** 1769,1774 ****
 > >> --- 1781,1792 ----
 > >> (progn
 > >> (setq output (gdb-concat-output output gud-marker-acc))
 > >> (setq gud-marker-acc "")))
 > >> +       (if (not (string-match "\n" gdb-first-output-line))
 > 
 > >            (if (gdb-first-post-prompt)
 > 
 > > would probably also work
 > 
 > I guess you meant "(if gdb-first-prompt", but whichever the variables,
 > I think its value might be changed in the while-loop in
 > gud-gdba-marker-filter via annotation handler calls.

Actually both probably come too late.

One problem with trying to match for "Apple" in the first output line is that
the user might use -q:

  nickrob@totara:~$ gdb -q myprog
  (gdb) 

To be safer you need to add something like:

  (gdb-enqueue-input (list "server show version\n" 'gdb-apple-test)))

maybe at the start of gdb-init-2 and where gdb-apple-test inspects the
output of "show version" (the prefix server ensures that the user
doesn't see this command in the gdb history):

  ;; Workaround for some Apple versions of GDB that add ^M at EOL
  ;; after the command "server interpreter mi -stack-info-frame".
  (defun gdb-apple-test ()
  (goto-char (point-min))
  (if (re-search-forward "(Apple version " nil t)
      (setq gdb-version "pre-6.4")
      (let* ((process (get-buffer-process gud-comint-buffer))
	     (coding-systems (process-coding-system process)))
	(set-process-coding-system process
				   (coding-system-change-eol-conversion
				    (car coding-systems) 'dos)
				   (cdr coding-systems))))))

To see how this works instrument gdb-apple-test with Edebug and look in
the " *partial-output-yourprog" buffer (note leading space means hidden
buffer).

 >                                                         If we want to
 > avoid string-match for most cases, then we can save the original value
 > at the beginning of the while-loop to some variable (say,
 > orig-gdb-first-prompt) and use it like this:

The above patch would avoid continually matching in gud-gdba-marker-filter
too.

WDYT?

-- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: GDB on Mac is (NOT) Broken

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 21 Mar 2010 19:50:41 +1300, nickrob@snap.net.nz (Nick Roberts) said:

> To be safer you need to add something like:

>   (gdb-enqueue-input (list "server show version\n" 'gdb-apple-test)))

> maybe at the start of gdb-init-2 and where gdb-apple-test inspects the
> output of "show version" (the prefix server ensures that the user
> doesn't see this command in the gdb history):

>   ;; Workaround for some Apple versions of GDB that add ^M at EOL
>   ;; after the command "server interpreter mi -stack-info-frame".
>   (defun gdb-apple-test ()
>   (goto-char (point-min))
>   (if (re-search-forward "(Apple version " nil t)
>       (setq gdb-version "pre-6.4")
>       (let* ((process (get-buffer-process gud-comint-buffer))
> 	     (coding-systems (process-coding-system process)))
> 	(set-process-coding-system process
> 				   (coding-system-change-eol-conversion
> 				    (car coding-systems) 'dos)
> 				   (cdr coding-systems))))))

> To see how this works instrument gdb-apple-test with Edebug and look in
> the " *partial-output-yourprog" buffer (note leading space means hidden
> buffer).

>> If we want to
>> avoid string-match for most cases, then we can save the original value
>> at the beginning of the while-loop to some variable (say,
>> orig-gdb-first-prompt) and use it like this:

> The above patch would avoid continually matching in gud-gdba-marker-filter
> too.

> WDYT?

I think it's much cleaner.

I tried your code with removing the line (setq gdb-version "pre-6.4")
in gdb-apple-test, because set-process-coding-system should go to the
then-clause.

(I'm not familiar with this at all, but should Apple versions be
regarded as pre-6.4?  On Mac OS X 10.6, the first line looks like `GNU
gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18 20:40:51 UTC
2009)', and `server interpreter mi -stack-info-frame' results in
`^error,msg="No registers."'.)

It avoided the hang in completion, but in the
" *partial-output-yourprog*" buffer, ^M was already added because
"server show version\n" was executed after "server interpreter mi
-stack-info-frame\n" which triggered the addition of ^M.  How about
checking the result of "server show version\n" before "server
interpreter mi -stack-info-frame\n"?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: GDB on Mac is (NOT) Broken

[Nick Roberts]

 > I tried your code with removing the line (setq gdb-version "pre-6.4")
 > in gdb-apple-test, because set-process-coding-system should go to the
 > then-clause.

Yes, it shouldn't be there.  Sorry, it was just a cut and paste error
from gdb-get-version.

 > (I'm not familiar with this at all, but should Apple versions be
 > regarded as pre-6.4?  On Mac OS X 10.6, the first line looks like `GNU
 > gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18 20:40:51 UTC
 > 2009)', and `server interpreter mi -stack-info-frame' results in
 > `^error,msg="No registers."'.)

Apple generally merge in FSF GDB changes so they are broadly similar.  The
pre-6.4 tag is just a crude way of finding what MI features GDB will have and
does this by testing if -stack-info-frame is present.  Your actual version is
actually < 6.4 but I think we can leave this as it will be correct to a first
approximation.

 > It avoided the hang in completion, but in the
 > " *partial-output-yourprog*" buffer, ^M was already added because
 > "server show version\n" was executed after "server interpreter mi
 > -stack-info-frame\n" which triggered the addition of ^M.  How about
 > checking the result of "server show version\n" before "server
 > interpreter mi -stack-info-frame\n"?

Sure.  I don't think it matters to other platforms where it goes.

I think it should go in both the branch and the trunk but I defer to Stefan
or Cyd on the former.

-- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: GDB on Mac is (NOT) Broken

[Stefan Monnier]

> To be safer you need to add something like:
>   (gdb-enqueue-input (list "server show version\n" 'gdb-apple-test)))

That's probably better in some sense, but it's less "obviously safe for
GNU".  So I'd rather not install it into the emacs-23 branch.
OTOH feel free to install this "right fix" on the trunk.


        Stefan

Re: GDB on Mac is (NOT) Broken

[Nick Roberts]

 > > To be safer you need to add something like:
 > >   (gdb-enqueue-input (list "server show version\n" 'gdb-apple-test)))
 > 
 > That's probably better in some sense, but it's less "obviously safe for
 > GNU". ...

How is it unsafe?  What could go wrong?

-- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: GDB on Mac is (NOT) Broken

[Stefan Monnier]

>> > To be safer you need to add something like:
>> >   (gdb-enqueue-input (list "server show version\n" 'gdb-apple-test)))
>> That's probably better in some sense, but it's less "obviously safe for
>> GNU". ...
> How is it unsafe?

It changes the set of commands passed between Emacs and GDB, so it's not
obviously "safe" (in the sense of "cannot introduce a change in behavior").


        Stefan

Re: GDB on Mac is (NOT) Broken

[Nick Roberts]

 > > How is it unsafe?
 > 
 > It changes the set of commands passed between Emacs and GDB, so it's not
 > obviously "safe" (in the sense of "cannot introduce a change in behavior").


On platforms other than Apple's behaviour is unchanged: there is no match in
gdb-apple-test and it does nothing.  On Apple platforms, the coding-system
is changed but that behaviour has been tested by Mac users.

No change is risk free but I think this one is as safe as they come.

-- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: GDB on Mac is (NOT) Broken

[Stefan Monnier]

>> > How is it unsafe?
>> It changes the set of commands passed between Emacs and GDB, so it's not
>> obviously "safe" (in the sense of "cannot introduce a change in behavior").
> On platforms other than Apple's behaviour is unchanged: there is no match in
> gdb-apple-test and it does nothing.

How do you know that sending a command like "server show version" will
never have any effect at all neither on the GDB process nor on the Emacs
state nor on the synchronization between the two?
The things we've seen in the Emacs<->GDB interaction make me very
suspicious of such things.


        Stefan

Re: GDB on Mac is (NOT) Broken

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 22 Mar 2010 21:13:33 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

> How do you know that sending a command like "server show version"
> will never have any effect at all neither on the GDB process nor on
> the Emacs state nor on the synchronization between the two?  The
> things we've seen in the Emacs<->GDB interaction make me very
> suspicious of such things.

How about surrounding it with (if (eq system-type 'darwin) ...)?

BTW, personally I don't care that much whether the change is included
in Emacs 23.2 or deferred to the subsequent versions (I'll include it
into the next version of the Mac port in any case).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: GDB on Mac is (NOT) Broken

[Nick Roberts]

 > > How do you know that sending a command like "server show version"
 > > will never have any effect at all neither on the GDB process nor on
 > > the Emacs state nor on the synchronization between the two?  The
 > > things we've seen in the Emacs<->GDB interaction make me very
 > > suspicious of such things.

That sounds more like paranoia than reason.  

Unsurprisingly all "show version" does is output the version of GDB:

nickrob@totara:~$ gdb -q
(gdb) show version
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
(gdb) 

That's the same text that is output if "-q" isn't specified.

Unlike other commands, it doesn't change the state of the executable or the
debugger.  Parsing the output is no different in it's nature to the the many
other lisp functions that already do this except that some of those _do_
change the state of the executable or the debugger

 > How about surrounding it with (if (eq system-type 'darwin) ...)?

I don't think that should really be necessary.

 > BTW, personally I don't care that much whether the change is included
 > in Emacs 23.2 or deferred to the subsequent versions (I'll include it
 > into the next version of the Mac port in any case).

Likewise it's not that important to me either: I don't currently use a Mac.  I'm
just trying to react to the bug reports that have been made.

-- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: GDB on Mac is (NOT) Broken

[Stefan Monnier]

>> How about surrounding it with (if (eq system-type 'darwin) ...)?
> I don't think that should really be necessary.

It would make it "obviously safe for GNU", so it'd make it acceptable
for 23.2 AFAIC.


        Stefan

Re: GDB on Mac is (NOT) Broken

[Nick Roberts]

 > How about surrounding it with (if (eq system-type 'darwin) ...)?

I think I've done this now on the emacs-23 branch.  Since I'm not familiar
with Bzr I and don't have access to a Mac, someone might like to check the
change.  It doesn't appear to change anything on GNU/Linux.

-- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: GDB on Mac is (NOT) Broken

[Stefan Monnier]

>> How about surrounding it with (if (eq system-type 'darwin) ...)?
> I think I've done this now on the emacs-23 branch.

Thanks,


        Stefan

Re: GDB on Mac is (NOT) Broken

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 26 Mar 2010 22:02:36 +1300, nickrob@snap.net.nz (Nick Roberts) said:

> I think I've done this now on the emacs-23 branch.  Since I'm not
> familiar with Bzr I and don't have access to a Mac, someone might
> like to check the change.  It doesn't appear to change anything on
> GNU/Linux.

I tested it with on Mac OS X 10.6 (X11 build).  It no longer hangs
with completion.  Thanks.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: GDB on Mac is (NOT) Broken

[Leo]

On 2010-03-16 00:18 +0000, YAMAMOTO Mitsuharu wrote:
> The simplest workaround would be something like (push '("\\`gdb\\'"
> . (utf-8-dos . utf-8-unix)) process-coding-system-alist).  But
> detecting Apple versions of GDB would be better.  Could you check the
> patch below?

I tested this patch with 23.1.94 and it worked nicely. Thanks.

Leo

Re: GDB on Mac is (NOT) Broken

[Stefan Monnier]

> +   ;; Workaround for some Apple versions of GDB that add ^M at EOL
> +   ;; after the command "server interpreter mi -stack-info-frame".
> +   (if (string-match "(Apple version " gdb-first-output-line)
> +       (let* ((process (get-buffer-process gud-comint-buffer))
> + 	     (coding-systems (process-coding-system process)))
> + 	(set-process-coding-system process
> + 				   (coding-system-change-eol-conversion
> + 				    (car coding-systems) 'dos)
> + 				   (cdr coding-systems))))
> + 

Actually, detecting the CRLF itself would be better.  But at least this
seems "safe for GNU".  So I think it's acceptable for 23.2.

> +       (if (not (string-match "\n" gdb-first-output-line))
> + 	  (setq gdb-first-output-line
> + 		(concat gdb-first-output-line
> + 			(if (string-match "\n" output)
> + 			    (substring output 0 (match-end 0))
> + 			  output))))
>         output)))
  
Rather than string-match, you can
(eq ?\n (aref gdb-first-output-line (1- (length gdb-first-output-line))))


        Stefan

Re: GDB on Mac is (NOT) Broken

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 20 Mar 2010 15:45:59 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> +   ;; Workaround for some Apple versions of GDB that add ^M at EOL
>> +   ;; after the command "server interpreter mi -stack-info-frame".
>> +   (if (string-match "(Apple version " gdb-first-output-line)
>> +       (let* ((process (get-buffer-process gud-comint-buffer))
>> + 	     (coding-systems (process-coding-system process)))
>> + 	(set-process-coding-system process
>> + 				   (coding-system-change-eol-conversion
>> + 				    (car coding-systems) 'dos)
>> + 				   (cdr coding-systems))))
>> + 

> Actually, detecting the CRLF itself would be better.  But at least this
> seems "safe for GNU".  So I think it's acceptable for 23.2.

Strangely, the EOL style suddenly changes from LF to CRLF after the
command "server interpreter mi -stack-info-frame", .  I.e., the first
output line ends with LF.  Maybe I'll improve the comment.

>> +       (if (not (string-match "\n" gdb-first-output-line))
>> + 	  (setq gdb-first-output-line
>> + 		(concat gdb-first-output-line
>> + 			(if (string-match "\n" output)
>> + 			    (substring output 0 (match-end 0))
>> + 			  output))))
>> output)))
  
> Rather than string-match, you can
> (eq ?\n (aref gdb-first-output-line (1- (length gdb-first-output-line))))

Currently, gdb-first-output-line is initialized to "".  And I thought

  (and (not (string= gdb-first-output-line "")
       (eq ?\n (aref gdb-first-output-line
                     (1- (length gdb-first-output-line))))

a bit awkward and doubted its merit because it involves more
bytecode-level operations.  Of course, one can initialize the variable
to some dummy non-empty string, but it doesn't look natural.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp