* emacs 23 gdb mouse set breakpoint
@ 2009-04-08 4:23 Ritchie
2009-04-08 7:55 ` Nick Roberts
[not found] ` <mailman.4877.1239185133.31690.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 16+ messages in thread
From: Ritchie @ 2009-04-08 4:23 UTC (permalink / raw
To: help-gnu-emacs
I started trying out emacs 23 cvs version, and I just had a problem
while using gdb. When I use carbon emacs on mac and emac 23 cvs
version on linux, I can set gdb breakpoint by clicking on the left
fringe of the source buffer, and there would be a red dot on that
location to indicate that there is a breakpoint on that line. If you
click on the red dot again, the breakpoint would be removed.
But it's quite different on emacs 23 cvs on mac. When I try to set the
breakpoint using my mouse, the breakpoint would be set, but there is
no red dot on the left fringe. And I cannot remove the breakpoint
using mouse, if I try to click on the same location again, it will set
another breakpoint on the same spot again. It's quite annoying,
especially if you are used to the old way. I don't know if anybody is
having or had the same problem like this, is there anyway to make it
behave the old way?
Also, there is another minor issue. If I set gdb-many-windows, in both
stack buffer and breakpoint buffer, there are many ^M characters shows
up. I'm not sure what caused it. Again this is with emac 23 cvs on
mac, while the linux version works quite well.
I tried the emacs-app-devel package in macport and the nightly emacs
23 cvs builds (0.91, 0.92), they all behave the same way.
regards
Ritchie
^ permalink raw reply [flat|nested] 16+ messages in thread
* emacs 23 gdb mouse set breakpoint
2009-04-08 4:23 emacs 23 gdb mouse set breakpoint Ritchie
@ 2009-04-08 7:55 ` Nick Roberts
[not found] ` <mailman.4877.1239185133.31690.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 16+ messages in thread
From: Nick Roberts @ 2009-04-08 7:55 UTC (permalink / raw
To: Ritchie; +Cc: help-gnu-emacs
> But it's quite different on emacs 23 cvs on mac. When I try to set the
> breakpoint using my mouse, the breakpoint would be set, but there is
> no red dot on the left fringe. And I cannot remove the breakpoint
> using mouse, if I try to click on the same location again, it will set
> another breakpoint on the same spot again. It's quite annoying,
> especially if you are used to the old way. I don't know if anybody is
> having or had the same problem like this, is there anyway to make it
> behave the old way?
I see this with Apple Gdb which comes with Mac OSX. This version differs
slightly from FSF Gdb and is adapted for use with Apple's Xcode. The latest
FSF Gdb in the repository (http://sources.redhat.com/gdb/current/) now
compiles on Darwin and Mac OSX and doesn't have the problems you see. If you
don't want to build Gdb, the next version FSF Gdb will be 7.0 and it should be
released in June.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
[not found] ` <mailman.4877.1239185133.31690.help-gnu-emacs@gnu.org>
@ 2009-04-08 15:30 ` armando.sano
2009-04-09 7:40 ` Nick Roberts
[not found] ` <mailman.4959.1239262862.31690.help-gnu-emacs@gnu.org>
2009-04-09 1:59 ` Ritchie
1 sibling, 2 replies; 16+ messages in thread
From: armando.sano @ 2009-04-08 15:30 UTC (permalink / raw
To: help-gnu-emacs
I just noticed exactly the same problems as Ritchie with a fresh cvs
build of Emacs 23[0.92.1] on mac (os x 10.4.11, PowerBook G4).
However, older version of Emacs (22.0.50.1 in my case) on the same mac
does not have this problem. The breakpoints work as expected and there
are not ^M everywhere in gdb-many-windows mode. Is it then really a
problem of gdb being modified by apple? Has anybody tried to build FSF
gdb to see if the problem goes away?
Regards
Armando
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
[not found] ` <mailman.4877.1239185133.31690.help-gnu-emacs@gnu.org>
2009-04-08 15:30 ` armando.sano
@ 2009-04-09 1:59 ` Ritchie
2009-04-09 4:10 ` Ritchie
2009-04-09 7:30 ` Nick Roberts
1 sibling, 2 replies; 16+ messages in thread
From: Ritchie @ 2009-04-09 1:59 UTC (permalink / raw
To: help-gnu-emacs
Thanks for your reply.
So you think it's because of different GDB version? But I also run
carbon emacs, which is emacs 22.3, on my mac, and I've been using it
for quite a long time, everything seems to be alright on that one.
Since the two are using the same gdb on the same machine, I assume it
should be something to do with emacs 23 cvs for Mac.
But I'm going to try out the new version of GDB anyway. I'll see what
happens.
regards
Ritchie
On Apr 8, 12:55 am, nick...@snap.net.nz (Nick Roberts) wrote:
> I see this with Apple Gdb which comes with Mac OSX. This version differs
> slightly from FSF Gdb and is adapted for use with Apple's Xcode. The latest
> FSF Gdb in the repository (http://sources.redhat.com/gdb/current/) now
> compiles on Darwin and Mac OSX and doesn't have the problems you see. If you
> don't want to build Gdb, the next version FSF Gdb will be 7.0 and it should be
> released in June.
>
> --
> Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
2009-04-09 1:59 ` Ritchie
@ 2009-04-09 4:10 ` Ritchie
2009-04-09 7:34 ` Nick Roberts
2009-04-09 7:30 ` Nick Roberts
1 sibling, 1 reply; 16+ messages in thread
From: Ritchie @ 2009-04-09 4:10 UTC (permalink / raw
To: help-gnu-emacs
Well, no luck with gdb-6.8. I tried macport, there is a gdb package,
but after "build", it will only install three files:
Port gdb contains:
/opt/local/lib/libiberty.a
/opt/local/share/info/configure.info
/opt/local/share/info/standards.info
I then downloaded gdb-6.8 source. The compilation process did went
through, but when I do a "make install", it says nothing to make.
Looks like, we'll have to depends on Apple to release newer version of
gdb.
So I'll just stick with emacs22.3 on my Mac.
regards
Ritchie
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
2009-04-09 1:59 ` Ritchie
2009-04-09 4:10 ` Ritchie
@ 2009-04-09 7:30 ` Nick Roberts
2009-04-09 8:48 ` Peter Dyballa
1 sibling, 1 reply; 16+ messages in thread
From: Nick Roberts @ 2009-04-09 7:30 UTC (permalink / raw
To: Ritchie; +Cc: help-gnu-emacs
> So you think it's because of different GDB version? But I also run
> carbon emacs, which is emacs 22.3, on my mac, and I've been using it
> for quite a long time, everything seems to be alright on that one.
> Since the two are using the same gdb on the same machine, I assume it
> should be something to do with emacs 23 cvs for Mac.
No I'm just saying that, on Mac OSX, the repository version of FSF Gdb appears to
work with the repository version of Emacs. This version of Emacs is built with
Cocoa, although I don't know what that means in practice. I think if you
find a way to filter out the ^M characters in the output of Gdb, then breakpoints
will also work in the margin. That presumably has something to do with the way
Cocoa Emacs interprets line endings.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
2009-04-09 4:10 ` Ritchie
@ 2009-04-09 7:34 ` Nick Roberts
0 siblings, 0 replies; 16+ messages in thread
From: Nick Roberts @ 2009-04-09 7:34 UTC (permalink / raw
To: Ritchie; +Cc: help-gnu-emacs
Ritchie writes:
> Well, no luck with gdb-6.8. I tried macport, there is a gdb package,
> but after "build", it will only install three files:
> Port gdb contains:
> /opt/local/lib/libiberty.a
> /opt/local/share/info/configure.info
> /opt/local/share/info/standards.info
>
> I then downloaded gdb-6.8 source. The compilation process did went
> through, but when I do a "make install", it says nothing to make.
> Looks like, we'll have to depends on Apple to release newer version of
> gdb.
That's what I said in my e-mail: it needs 7.0 (not yet released).
> So I'll just stick with emacs22.3 on my Mac.
That might work well enough for your needs but there are probably other
things that don't work with this version of Gdb. In future, when Emacs
uses GDB/MI, these differences will become greater and FSF Gdb will become
more necessary.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
2009-04-08 15:30 ` armando.sano
@ 2009-04-09 7:40 ` Nick Roberts
[not found] ` <mailman.4959.1239262862.31690.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 16+ messages in thread
From: Nick Roberts @ 2009-04-09 7:40 UTC (permalink / raw
To: armando.sano; +Cc: help-gnu-emacs
armando.sano@gmail.com writes:
> I just noticed exactly the same problems as Ritchie with a fresh cvs
> build of Emacs 23[0.92.1] on mac (os x 10.4.11, PowerBook G4).
> However, older version of Emacs (22.0.50.1 in my case) on the same mac
> does not have this problem. The breakpoints work as expected and there
> are not ^M everywhere in gdb-many-windows mode.
Equally CVS FSF gdb works with CVS Emacs on Mac OSX.
> Is it then really a
> problem of gdb being modified by apple?
It is probably possible to fix CVS Emacs to work with Apple Gdb, as I
described to Ritchie, but I'm no longer looking for a way to do this.
> Has anybody tried to build FSF
> gdb to see if the problem goes away?
Yes, I have, as I previously stated. Perhaps you mean someone else. Probably
not.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
2009-04-09 7:30 ` Nick Roberts
@ 2009-04-09 8:48 ` Peter Dyballa
2009-04-09 22:20 ` Nick Roberts
0 siblings, 1 reply; 16+ messages in thread
From: Peter Dyballa @ 2009-04-09 8:48 UTC (permalink / raw
To: Nick Roberts; +Cc: help-gnu-emacs, Ritchie
Am 09.04.2009 um 09:30 schrieb Nick Roberts:
> I think if you find a way to filter out the ^M characters in the
> output of Gdb, then breakpoints will also work in the margin. That
> presumably has something to do with the way Cocoa Emacs interprets
> line endings.
I don't think it's a problem of "Cocoa Emacs" (or Emacs.app – it has
just a different, a Mac OS X native clothing), I'm seeing a similar
problem with Perl in the X client version. Apple's Gdb and Perl
obviously are in a Mac OS X mode, meaning that they use CR or ^M as
line ending. Wouldn't a change of the buffer's encoding solve the
problem? (Could be set up automatically if successful.)
--
Greetings
Pete
Make it simple, as simple as possible but no simpler.
– Albert Einstein
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
[not found] ` <mailman.4959.1239262862.31690.help-gnu-emacs@gnu.org>
@ 2009-04-09 16:20 ` armando.sano
2009-04-09 22:17 ` Nick Roberts
[not found] ` <mailman.5006.1239316899.31690.help-gnu-emacs@gnu.org>
2009-04-09 17:09 ` Ritchie
1 sibling, 2 replies; 16+ messages in thread
From: armando.sano @ 2009-04-09 16:20 UTC (permalink / raw
To: help-gnu-emacs
> It is probably possible to fix CVS Emacs to work with Apple Gdb, as I
> described to Ritchie, but I'm no longer looking for a way to do this.
Fixing cvs Emacs, however, would be nice in the mean time, before FSF
gdb 7 is released, especially if the fix is as simple as some line-
ending-encoding problem. Will see if I encounter something simple (but
my skills there - and time - are probably limited).
> > Has anybody tried to build FSF
> > gdb to see if the problem goes away?
>
> Yes, I have, as I previously stated. Perhaps you mean someone else. Probably
> not.
Ok, sorry, I wasn't sure about that before. Thanks for confirming that
point.
Armando
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
[not found] ` <mailman.4959.1239262862.31690.help-gnu-emacs@gnu.org>
2009-04-09 16:20 ` armando.sano
@ 2009-04-09 17:09 ` Ritchie
2009-04-09 21:56 ` Nick Roberts
1 sibling, 1 reply; 16+ messages in thread
From: Ritchie @ 2009-04-09 17:09 UTC (permalink / raw
To: help-gnu-emacs
On Apr 9, 12:40 am, nick...@snap.net.nz (Nick Roberts) wrote:
> armando.s...@gmail.com writes:
> > Has anybody tried to build FSF
> > gdb to see if the problem goes away?
>
> Yes, I have, as I previously stated. Perhaps you mean someone else. Probably
> not.
>
Just curious, which version of 6.8 have you tested? Were having
problems at the beginning? Do you still have the source of that
version somewhere?
I have tried all the cvs versions available in the repos, but non of
them worked. These are the packages I tried:
gdb-6.8.50.20090407
gdb-6.8.50.20090408
gdb-6.8.50.20090409
gdb-weekly-6.8.50.20090324
They are all having the same problem, here is the compiling error
(actually warnings):
make all-am
make[3]: Nothing to be done for `all-am'.
gcc-4.2 -g -O2 -I. -I.././gdb -I.././gdb/common -I.././gdb/config -
DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I.././gdb/../
include/opcode -I.././gdb/../readline/.. -I../bfd -I.././gdb/../bfd -
I.././gdb/../include -I../libdecnumber -I.././gdb/../libdecnumber -
I./../intl -I.././gdb/gnulib -Ignulib -DMI_OUT=1 -DTUI=1 -Wall -
Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-
pointer-sign -Wno-unused -Wno-switch -Wno-char-subscripts -Werror -c -
o amd64-tdep.o -MT amd64-tdep.o -MMD -MP -MF .deps/amd64-tdep.Tpo
amd64-tdep.c
cc1: warnings being treated as errors
In file included from inferior.h:35,
from amd64-tdep.c:32:
breakpoint.h: In function ‘VEC_bp_location_p_last’:
breakpoint.h:343: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_bp_location_p_index’:
breakpoint.h:343: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_bp_location_p_space’:
breakpoint.h:343: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_bp_location_p_quick_push’:
breakpoint.h:343: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_bp_location_p_pop’:
breakpoint.h:343: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_bp_location_p_truncate’:
breakpoint.h:343: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_bp_location_p_replace’:
breakpoint.h:343: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_bp_location_p_quick_insert’:
breakpoint.h:343: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_bp_location_p_ordered_remove’:
breakpoint.h:343: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_bp_location_p_unordered_remove’:
breakpoint.h:343: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_bp_location_p_block_remove’:
breakpoint.h:343: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_bp_location_p_safe_grow’:
breakpoint.h:343: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_breakpoint_p_last’:
breakpoint.h:471: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_breakpoint_p_index’:
breakpoint.h:471: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_breakpoint_p_space’:
breakpoint.h:471: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_breakpoint_p_quick_push’:
breakpoint.h:471: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_breakpoint_p_pop’:
breakpoint.h:471: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_breakpoint_p_truncate’:
breakpoint.h:471: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_breakpoint_p_replace’:
breakpoint.h:471: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_breakpoint_p_quick_insert’:
breakpoint.h:471: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_breakpoint_p_ordered_remove’:
breakpoint.h:471: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_breakpoint_p_unordered_remove’:
breakpoint.h:471: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_breakpoint_p_block_remove’:
breakpoint.h:471: warning: format not a string literal, argument types
not checked
breakpoint.h: In function ‘VEC_breakpoint_p_safe_grow’:
breakpoint.h:471: warning: format not a string literal, argument types
not checked
In file included from target.h:56,
from inferior.h:38,
from amd64-tdep.c:32:
memattr.h: In function ‘VEC_mem_region_s_last’:
memattr.h:98: warning: format not a string literal, argument types not
checked
memattr.h: In function ‘VEC_mem_region_s_index’:
memattr.h:98: warning: format not a string literal, argument types not
checked
memattr.h: In function ‘VEC_mem_region_s_space’:
memattr.h:98: warning: format not a string literal, argument types not
checked
memattr.h: In function ‘VEC_mem_region_s_quick_push’:
memattr.h:98: warning: format not a string literal, argument types not
checked
memattr.h: In function ‘VEC_mem_region_s_pop’:
memattr.h:98: warning: format not a string literal, argument types not
checked
memattr.h: In function ‘VEC_mem_region_s_truncate’:
memattr.h:98: warning: format not a string literal, argument types not
checked
memattr.h: In function ‘VEC_mem_region_s_replace’:
memattr.h:98: warning: format not a string literal, argument types not
checked
memattr.h: In function ‘VEC_mem_region_s_quick_insert’:
memattr.h:98: warning: format not a string literal, argument types not
checked
memattr.h: In function ‘VEC_mem_region_s_ordered_remove’:
memattr.h:98: warning: format not a string literal, argument types not
checked
memattr.h: In function ‘VEC_mem_region_s_unordered_remove’:
memattr.h:98: warning: format not a string literal, argument types not
checked
memattr.h: In function ‘VEC_mem_region_s_block_remove’:
memattr.h:98: warning: format not a string literal, argument types not
checked
memattr.h: In function ‘VEC_mem_region_s_safe_grow’:
memattr.h:98: warning: format not a string literal, argument types not
checked
In file included from inferior.h:38,
from amd64-tdep.c:32:
target.h: In function ‘VEC_memory_write_request_s_last’:
target.h:688: warning: format not a string literal, argument types not
checked
target.h: In function ‘VEC_memory_write_request_s_index’:
target.h:688: warning: format not a string literal, argument types not
checked
target.h: In function ‘VEC_memory_write_request_s_space’:
target.h:688: warning: format not a string literal, argument types not
checked
target.h: In function ‘VEC_memory_write_request_s_quick_push’:
target.h:688: warning: format not a string literal, argument types not
checked
target.h: In function ‘VEC_memory_write_request_s_pop’:
target.h:688: warning: format not a string literal, argument types not
checked
target.h: In function ‘VEC_memory_write_request_s_truncate’:
target.h:688: warning: format not a string literal, argument types not
checked
target.h: In function ‘VEC_memory_write_request_s_replace’:
target.h:688: warning: format not a string literal, argument types not
checked
target.h: In function ‘VEC_memory_write_request_s_quick_insert’:
target.h:688: warning: format not a string literal, argument types not
checked
target.h: In function ‘VEC_memory_write_request_s_ordered_remove’:
target.h:688: warning: format not a string literal, argument types not
checked
target.h: In function ‘VEC_memory_write_request_s_unordered_remove’:
target.h:688: warning: format not a string literal, argument types not
checked
target.h: In function ‘VEC_memory_write_request_s_block_remove’:
target.h:688: warning: format not a string literal, argument types not
checked
target.h: In function ‘VEC_memory_write_request_s_safe_grow’:
target.h:688: warning: format not a string literal, argument types not
checked
amd64-tdep.c: In function ‘amd64_register_type’:
amd64-tdep.c:113: warning: format not a string literal and no format
arguments
amd64-tdep.c: In function ‘amd64_dwarf_reg_to_regnum’:
amd64-tdep.c:200: warning: format not a string literal, argument types
not checked
amd64-tdep.c: In function ‘amd64_arch_reg_to_regnum’:
amd64-tdep.c:236: warning: format not a string literal, argument types
not checked
amd64-tdep.c: In function ‘amd64_classify_aggregate’:
amd64-tdep.c:347: warning: format not a string literal, argument types
not checked
amd64-tdep.c:360: warning: format not a string literal, argument types
not checked
amd64-tdep.c: In function ‘amd64_return_value’:
amd64-tdep.c:445: warning: format not a string literal, argument types
not checked
amd64-tdep.c:474: warning: format not a string literal, argument types
not checked
amd64-tdep.c:475: warning: format not a string literal, argument types
not checked
amd64-tdep.c:499: warning: format not a string literal, argument types
not checked
amd64-tdep.c:515: warning: format not a string literal, argument types
not checked
amd64-tdep.c:525: warning: format not a string literal, argument types
not checked
amd64-tdep.c:528: warning: format not a string literal, argument types
not checked
amd64-tdep.c: In function ‘amd64_push_arguments’:
amd64-tdep.c:613: warning: format not a string literal, argument types
not checked
amd64-tdep.c:631: warning: format not a string literal, argument types
not checked
amd64-tdep.c:637: warning: format not a string literal, argument types
not checked
amd64-tdep.c:640: warning: format not a string literal, argument types
not checked
amd64-tdep.c: In function ‘amd64_get_unused_input_int_reg’:
amd64-tdep.c:943: warning: format not a string literal, argument types
not checked
amd64-tdep.c:944: warning: format not a string literal, argument types
not checked
amd64-tdep.c:957: warning: format not a string literal and no format
arguments
amd64-tdep.c: In function ‘amd64_skip_prologue’:
amd64-tdep.c:1637: warning: large integer implicitly truncated to
unsigned type
amd64-tdep.c: In function ‘amd64_frame_prev_register’:
amd64-tdep.c:1743: warning: format not a string literal, argument
types not checked
amd64-tdep.c: In function ‘amd64_sigtramp_frame_cache’:
amd64-tdep.c:1789: warning: format not a string literal, argument
types not checked
amd64-tdep.c:1790: warning: format not a string literal, argument
types not checked
amd64-tdep.c: In function ‘amd64_sigtramp_frame_sniffer’:
amd64-tdep.c:1841: warning: format not a string literal, argument
types not checked
amd64-tdep.c: In function ‘amd64_supply_fpregset’:
amd64-tdep.c:1905: warning: format not a string literal, argument
types not checked
amd64-tdep.c: In function ‘amd64_collect_fpregset’:
amd64-tdep.c:1921: warning: format not a string literal, argument
types not checked
make: *** [amd64-tdep.o] Error 1
Did you have the same problem?
Thank you
Ritchie
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
2009-04-09 17:09 ` Ritchie
@ 2009-04-09 21:56 ` Nick Roberts
0 siblings, 0 replies; 16+ messages in thread
From: Nick Roberts @ 2009-04-09 21:56 UTC (permalink / raw
To: Ritchie; +Cc: help-gnu-emacs
> Just curious, which version of 6.8 have you tested? Were having
> problems at the beginning? Do you still have the source of that
> version somewhere?
I've checked GDB out from the CVS repository:
cvs -d :pserver:anoncvs@sourceware.org:/cvs/src co gdb
> I have tried all the cvs versions available in the repos, but non of
> them worked. These are the packages I tried:
>
> gdb-6.8.50.20090407
> gdb-6.8.50.20090408
> gdb-6.8.50.20090409
> gdb-weekly-6.8.50.20090324
These should work too but checking out from CVS allows you to keep
updating more easily and maybe even contribute patches.
> They are all having the same problem, here is the compiling error
> (actually warnings):
A while ago I modified Makefile.in (in the gdb directory? - I can't see
now as I only use Mac OSX at work.) to remove the -Werror option which
reports (the apparently harmless) warnings as errors. It appears that
the source of the warings must not have been fixed, so I guess there
aren't many people using this port (although this might be the wrong
conclusion)
> make all-am
> make[3]: Nothing to be done for `all-am'.
> gcc-4.2 -g -O2 -I. -I.././gdb -I.././gdb/common -I.././gdb/config -
> DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I.././gdb/../
> include/opcode -I.././gdb/../readline/.. -I../bfd -I.././gdb/../bfd -
> I.././gdb/../include -I../libdecnumber -I.././gdb/../libdecnumber -
> I./../intl -I.././gdb/gnulib -Ignulib -DMI_OUT=1 -DTUI=1 -Wall -
> Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-
> pointer-sign -Wno-unused -Wno-switch -Wno-char-subscripts -Werror -c -
^^^^^^^
It should compile without this.
> o amd64-tdep.o -MT amd64-tdep.o -MMD -MP -MF .deps/amd64-tdep.Tpo
> amd64-tdep.c
> cc1: warnings being treated as errors
> In file included from inferior.h:35,
> from amd64-tdep.c:32:
> breakpoint.h: In function ?VEC_bp_location_p_last?:
> breakpoint.h:343: warning: format not a string literal, argument types
> not checked
>...
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
2009-04-09 16:20 ` armando.sano
@ 2009-04-09 22:17 ` Nick Roberts
[not found] ` <mailman.5006.1239316899.31690.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 16+ messages in thread
From: Nick Roberts @ 2009-04-09 22:17 UTC (permalink / raw
To: armando.sano; +Cc: help-gnu-emacs
armando.sano@gmail.com writes:
> > It is probably possible to fix CVS Emacs to work with Apple Gdb, as I
> > described to Ritchie, but I'm no longer looking for a way to do this.
>
> Fixing cvs Emacs, however, would be nice in the mean time, before FSF
> gdb 7 is released, especially if the fix is as simple as some line-
> ending-encoding problem. Will see if I encounter something simple (but
> my skills there - and time - are probably limited).
It doesn't need to be fixed before FSF gdb 7 is released but before Emacs 23 is released.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
2009-04-09 8:48 ` Peter Dyballa
@ 2009-04-09 22:20 ` Nick Roberts
0 siblings, 0 replies; 16+ messages in thread
From: Nick Roberts @ 2009-04-09 22:20 UTC (permalink / raw
To: Peter Dyballa; +Cc: help-gnu-emacs, Ritchie
> I don't think it's a problem of "Cocoa Emacs" (or Emacs.app ? it has
> just a different, a Mac OS X native clothing), I'm seeing a similar
> problem with Perl in the X client version. Apple's Gdb and Perl
> obviously are in a Mac OS X mode, meaning that they use CR or ^M as
> line ending. Wouldn't a change of the buffer's encoding solve the
> problem? (Could be set up automatically if successful.)
If you (or someone else) can post a patch then I will apply it. It would
probably be small enough to apply without an assignment. The only requirement
would be that it doesn't break things for FSF GDB.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
[not found] ` <mailman.5006.1239316899.31690.help-gnu-emacs@gnu.org>
@ 2009-04-10 3:44 ` Ritchie
2009-04-11 10:39 ` Ritchie
0 siblings, 1 reply; 16+ messages in thread
From: Ritchie @ 2009-04-10 3:44 UTC (permalink / raw
To: help-gnu-emacs
Well, it's a success!
Turns out that I don't have to modify anything. You just have to run
the configure with --diable-werror option, that will do the job.
And when I run it with emacs, I have to pass a -nw option. cuz it
looks like the 6.8 comes with a gui interface, and the executable is
call gdbtui instead of gdb.
Now with 6.8.50, all the weird behaviors I described above are gone.
As to how good it is, only time will tell, I hope it doesn't crash too
often.
Thanks for you help Nick, this is the second time already~.
Ritchie
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: emacs 23 gdb mouse set breakpoint
2009-04-10 3:44 ` Ritchie
@ 2009-04-11 10:39 ` Ritchie
0 siblings, 0 replies; 16+ messages in thread
From: Ritchie @ 2009-04-11 10:39 UTC (permalink / raw
To: help-gnu-emacs
However, the 6.8.50 does not work ... It crashes with "Recursive
internal problem" error, even when I was trying to run a simple
"hello, world" program. Not sure if anybody else has had the same
problem.
regards
Ritchie
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2009-04-11 10:39 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-04-08 4:23 emacs 23 gdb mouse set breakpoint Ritchie
2009-04-08 7:55 ` Nick Roberts
[not found] ` <mailman.4877.1239185133.31690.help-gnu-emacs@gnu.org>
2009-04-08 15:30 ` armando.sano
2009-04-09 7:40 ` Nick Roberts
[not found] ` <mailman.4959.1239262862.31690.help-gnu-emacs@gnu.org>
2009-04-09 16:20 ` armando.sano
2009-04-09 22:17 ` Nick Roberts
[not found] ` <mailman.5006.1239316899.31690.help-gnu-emacs@gnu.org>
2009-04-10 3:44 ` Ritchie
2009-04-11 10:39 ` Ritchie
2009-04-09 17:09 ` Ritchie
2009-04-09 21:56 ` Nick Roberts
2009-04-09 1:59 ` Ritchie
2009-04-09 4:10 ` Ritchie
2009-04-09 7:34 ` Nick Roberts
2009-04-09 7:30 ` Nick Roberts
2009-04-09 8:48 ` Peter Dyballa
2009-04-09 22:20 ` Nick Roberts
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.