* 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
[parent not found: <mailman.4877.1239185133.31690.help-gnu-emacs@gnu.org>]
* 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 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
[parent not found: <mailman.4959.1239262862.31690.help-gnu-emacs@gnu.org>]
* 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 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
[parent not found: <mailman.5006.1239316899.31690.help-gnu-emacs@gnu.org>]
* 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
* 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 [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 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-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 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 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
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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).