GDB on Mac is Broken

GDB on Mac is Broken

[Leo]

Hello,

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?

Thanks.

Leo

Re: GDB on Mac is Broken

[Glenn Morris]

This is a duplicate of

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5712

but presumably refers to GNU Emacs now.

Re: GDB on Mac is Broken

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 12 Mar 2010 12:43:31 -0500, Glenn Morris <rgm@gnu.org> said:

> This is a duplicate of

> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5712

> but presumably refers to GNU Emacs now.

As expected, reproducibility on the Mac port could contribute to show
whether a bug was NS-specific or not.

The related difference between Emacs 22, on which the completion
works, and Emacs 23 seems to be:

  1. The default value of default-process-coding-system.
  2. A change in comint-exec-1.

For the first one, the value is (mule-utf-8 . mule-utf-8) in Emacs 22,
and (utf-8-unix . utf-8-unix) in Emacs 23 on Mac OS X 10.6.  The
difference in the EOL conversion comes from the following code in
mule-cmd.el:

  (let ((output-coding
	 ;; When bootstrapping, coding-systems are not defined yet, so
	 ;; we need to catch the error from check-coding-system.
	 (condition-case nil
	     (coding-system-change-text-conversion
	      (car default-process-coding-system) 'undecided)
	   (coding-system-error 'undecided)))
	(input-coding
	 (condition-case nil
	     (coding-system-change-text-conversion
	      (cdr default-process-coding-system) 'iso-latin-1)
	   (coding-system-error 'iso-latin-1))))
    (setq default-process-coding-system
	  (cons output-coding input-coding)))

The value of default-coding-system is nil as of bootstrapping, and the
following snippet evaluates to `undecided' on Emacs 22, but
`undecided-unix' on Emacs 23.

	 (condition-case nil
	     (coding-system-change-text-conversion
	      (car default-process-coding-system) 'undecided)
	   (coding-system-error 'undecided))

This difference in turn comes from that of (coding-system-eol-type
nil), which evaluates to nil on Emacs 22 and 0 on Emacs 23.

The second one is the first hunk in
http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00322.html

2008-03-04 Kenichi Handa  <address@hidden>

        * comint.el (comint-exec-1): Don't change the coding-system for
        decoding to dos-like EOL.

Index: comint.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/comint.el,v
retrieving revision 1.373
diff -c -r1.373 comint.el
*** comint.el   22 Jan 2008 23:53:43 -0000      1.373
--- comint.el   4 Mar 2008 11:41:44 -0000
***************
*** 800,811 ****
      (let ((coding-systems (process-coding-system proc)))
        (setq decoding (car coding-systems)
            encoding (cdr coding-systems)))
-     ;; If start-file-process decided to use some coding system for decoding
-     ;; data sent from the process and the coding system doesn't
-     ;; specify EOL conversion, we had better convert CRLF to LF.
-     (if (vectorp (coding-system-eol-type decoding))
-       (setq decoding (coding-system-change-eol-conversion decoding 'dos)
-             changed t))
      ;; Even if start-file-process left the coding system for encoding data
      ;; sent from the process undecided, we had better use the same one
      ;; as what we use for decoding.  But, we should suppress EOL

I'm not sure which side should be changed, gud or comint with
coding-system functions.  At least, the above differences explain why
completion in *gdb* buffer behaves differently between Emacs 22 and
23.

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

Re: GDB on Mac is Broken

[Eli Zaretskii]

> Date: Sat, 13 Mar 2010 15:58:11 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> The related difference between Emacs 22, on which the completion
> works, and Emacs 23 seems to be:
> 
>   1. The default value of default-process-coding-system.
>   2. A change in comint-exec-1.
> 
> For the first one, the value is (mule-utf-8 . mule-utf-8) in Emacs 22,
> and (utf-8-unix . utf-8-unix) in Emacs 23 on Mac OS X 10.6.

And what is wrong with the Emacs 23 default, exactly?  Doesn't OS X
use LF as the end-of-line character, when communicating with
subprocesses in general and with GDB in particular?

> At least, the above differences explain why completion in *gdb*
> buffer behaves differently between Emacs 22 and 23.

Could you please explain how these two differences explain the bug?
I'm afraid I don't see the immediate connection.

Re: GDB on Mac is Broken

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 13 Mar 2010 09:51:36 +0200, Eli Zaretskii <eliz@gnu.org> said:

>> Date: Sat, 13 Mar 2010 15:58:11 +0900 From: YAMAMOTO Mitsuharu
>> <mituharu@math.s.chiba-u.ac.jp>
>> 
>> The related difference between Emacs 22, on which the completion
>> works, and Emacs 23 seems to be:
>> 
>> 1. The default value of default-process-coding-system.  2. A change
>> in comint-exec-1.
>> 
>> For the first one, the value is (mule-utf-8 . mule-utf-8) in Emacs
>> 22, and (utf-8-unix . utf-8-unix) in Emacs 23 on Mac OS X 10.6.

> And what is wrong with the Emacs 23 default, exactly?  Doesn't OS X
> use LF as the end-of-line character, when communicating with
> subprocesses in general and with GDB in particular?

I've never said it's `wrong'; just different from Emacs 22, and that
leads to the different behavior for completion in GUD between Emacs 22
and 23.  It might be the case that what should be changed is at the
GUD or gdb side, but I don't know.

>> At least, the above differences explain why completion in *gdb*
>> buffer behaves differently between Emacs 22 and 23.

> Could you please explain how these two differences explain the bug?
> I'm afraid I don't see the immediate connection.

I should have been explained more why the difference in EOL conversion
affects this issue.  The hang in Emacs 23 on Mac OS X is caused by
unexpected ^M at EOL when processing gdb output.  Gdb actually outputs
^M, but GUD in Emacs 22 did not see ^M because it used dos (CRLF) EOL
conversion due to the comint code I showed in my previous mail.

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

Re: GDB on Mac is Broken

[Eli Zaretskii]

> Date: Sat, 13 Mar 2010 17:05:41 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: emacs-devel@gnu.org
> 
> I should have been explained more why the difference in EOL conversion
> affects this issue.  The hang in Emacs 23 on Mac OS X is caused by
> unexpected ^M at EOL when processing gdb output.  Gdb actually outputs
> ^M, but GUD in Emacs 22 did not see ^M because it used dos (CRLF) EOL
> conversion due to the comint code I showed in my previous mail.

Ah, thanks -- this is the missing piece, then.  Is this ^M specific to
OS X, or does it happen on GNU/Linux as well?  We should probably add
this info to the bug report (CC'ed).

In any case, I think it's GUD that needs to explicitly set the
decoding part of process-coding-system to handle CRLF, either on OS X
or on all platforms.  The two places you show whose changes contribute
to this problem are too general to modify them now in order to solve
this specific problem, IMO.

Re: GDB on Mac is Broken

[Glenn Morris]

Eli Zaretskii wrote:

> We should probably add this info to the bug report (CC'ed).

I was hoping to avoid having the discussion split over two lists, but
alas it was not to be. I wish people would not report bugs in two
places at the same time.

Re: GDB on Mac is Broken

[Leo]

On 2010-03-13 08:05 +0000, YAMAMOTO Mitsuharu wrote:
>> Could you please explain how these two differences explain the bug?
>> I'm afraid I don't see the immediate connection.
>
> I should have been explained more why the difference in EOL conversion
> affects this issue.  The hang in Emacs 23 on Mac OS X is caused by
> unexpected ^M at EOL when processing gdb output.  Gdb actually outputs
> ^M, but GUD in Emacs 22 did not see ^M because it used dos (CRLF) EOL
> conversion due to the comint code I showed in my previous mail.
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

Another oddity to this is if I change the process coding system
interactively by C-x RET p and give 'utf-8 for both values, the
completion will work because the coding is now:

(utf-8 . utf-8-unix)

but doing it in elisp as this:

(add-hook 'gud-mode-hook
          (lambda ()
            (set-buffer-process-coding-system 'utf-8 'utf-8)))

fails.

The process coding system is:

(utf-8-unix . utf-8-unix)

different to the interactive changed one.

I have found the exact same cause of the freeze and have been using this
workaround:

(add-hook 'gud-mode-hook
          (lambda ()
            (set-buffer-process-coding-system 'utf-8-dos 'utf-8)))

I also wish a proper fix is made available.

Best wishes,
Leo

Re: GDB on Mac is Broken

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Sat, 13 Mar 2010 16:03:14 +0000
> 
> Another oddity to this is if I change the process coding system
> interactively by C-x RET p and give 'utf-8 for both values, the
> completion will work because the coding is now:
> 
> (utf-8 . utf-8-unix)
> 
> but doing it in elisp as this:
> 
> (add-hook 'gud-mode-hook
>           (lambda ()
>             (set-buffer-process-coding-system 'utf-8 'utf-8)))
> 
> fails.

I think that's not an oddity, but expected behavior: you cannot call
set-buffer-process-coding-system in a mode hook, because that's not
the right moment for setting how process I/O will be decoded.

Re: GDB on Mac is Broken

[Miles Bader]

haha, is there any platform on which emacs-gdb _isn't_ broken...?

-Miles

-- 
Virtues, n. pl. Certain abstentions.

Re: GDB on Mac is Broken

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sat, 13 Mar 2010 12:49:38 +0900
> Cc: emacs-devel@gnu.org
> 
> haha, is there any platform on which emacs-gdb _isn't_ broken...?

I don't know what you are talking about.  I use it on GNU/Linux and on
MS-Windows, and it works just fine for me.

Re: GDB on Mac is Broken

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> haha, is there any platform on which emacs-gdb _isn't_ broken...?
>
> I don't know what you are talking about.  I use it on GNU/Linux and on
> MS-Windows, and it works just fine for me.

Hm, really?  It's just a complete mess when I use it (to the point where
reporting all the bugs seems just like a depressingly huge job, so I
keep putting it off...).

Are you using the new "MIS" mode (which I think is the default)?

Thanks,

-Miles

-- 
Egotist, n. A person of low taste, more interested in himself than in me.

Re: GDB on Mac is Broken

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sat, 13 Mar 2010 16:49:35 +0900
> Cc: sdl.web@gmail.com, emacs-devel@gnu.org
> 
> Are you using the new "MIS" mode (which I think is the default)?

No.  Didn't try that one yet.

Re: GDB on Mac is Broken

[Stefan Monnier]

> Hm, really?  It's just a complete mess when I use it (to the point where
> reporting all the bugs seems just like a depressingly huge job, so I
> keep putting it off...).

I use M-x gud-gdb and it's been working just about as well as M-x gdb
worked before the gdb-ui thingy was installed.


        Stefan

Re: GDB on Mac is Broken

[Leo]

On 2010-03-13 14:25 +0000, Stefan Monnier wrote:
>> Hm, really?  It's just a complete mess when I use it (to the point where
>> reporting all the bugs seems just like a depressingly huge job, so I
>> keep putting it off...).
>
> I use M-x gud-gdb and it's been working just about as well as M-x gdb
> worked before the gdb-ui thingy was installed.

Yes, this one seems better and it does not have the completion problem
that I reported.

>         Stefan

Best wishes,
Leo

Re: GDB on Mac is Broken

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Hm, really?  It's just a complete mess when I use it (to the point where
>> reporting all the bugs seems just like a depressingly huge job, so I
>> keep putting it off...).
>
> I use M-x gud-gdb and it's been working just about as well as M-x gdb
> worked before the gdb-ui thingy was installed.

Ah, so that basically invokes the old-style gdb mode?

Good to know ... I'd started just running gdb in a shell buffer instead!

-miles

-- 
`Life is a boundless sea of bitterness'

Re: GDB on Mac is Broken

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Hm, really?  It's just a complete mess when I use it (to the point where
>>> reporting all the bugs seems just like a depressingly huge job, so I
>>> keep putting it off...).
>>
>> I use M-x gud-gdb and it's been working just about as well as M-x gdb
>> worked before the gdb-ui thingy was installed.
>
> Ah, so that basically invokes the old-style gdb mode?
>
> Good to know ... I'd started just running gdb in a shell buffer instead!

(defalias 'gdb 'gud-gdb)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GDB on Mac is Broken

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sun, 14 Mar 2010 13:01:32 +0900
> Cc: Eli Zaretskii <eliz@gnu.org>, sdl.web@gmail.com, emacs-devel@gnu.org
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >> Hm, really?  It's just a complete mess when I use it (to the point where
> >> reporting all the bugs seems just like a depressingly huge job, so I
> >> keep putting it off...).
> >
> > I use M-x gud-gdb and it's been working just about as well as M-x gdb
> > worked before the gdb-ui thingy was installed.
> 
> Ah, so that basically invokes the old-style gdb mode?

For the record, I'm using the stock "M-x gdb", not gud-gdb.  ANd it
works for me just fine, at least with the annotations used as the GDB
interface.