[ESS] Running gdb under emacs 23.1 and attaching to an ess-based R process
Douglas Bates
bates at stat.wisc.edu
Sat Feb 5 17:45:16 CET 2011
On Mon, Jan 17, 2011 at 3:29 AM, Martin Maechler
<maechler at stat.math.ethz.ch> wrote:
>>>>>> Martin Maechler <maechler at stat.math.ethz.ch>
>>>>>> on Mon, 17 Jan 2011 10:15:17 +0100 writes:
>
>>>>>> Douglas Bates <bates at stat.wisc.edu>
>>>>>> on Wed, 12 Jan 2011 15:24:52 -0600 writes:
>
> >> In the past I had a wonderfully effective way of getting
> >> at compiled code in an R package with gdb. I would start
> >> R with ESS (M-x R) and load the package. Then I would
> >> start gdb on the binary (M-x gdb <RET>
> >> /usr/lib/R/bin/exec/R), find the process number of the R
> >> process (M-! pgrep R) and attach gdb to that
> >> already-running process. I would interrupt R, set
> >> breakpoints and then send the sig 0 signal.
>
> >> Now I am running emacs 23.1 (which, for some reason, is
> >> still called emacs-snapshot in Ubuntu) with enhanced
> >> support for gdb. M-x gdb ends up opening multiple windows
> >> and I can't get things straightened out to have the input
> >> and output from the attached process associated with the
> >> *R* buffer.
>
> >> Has anyone been able to run the gdb/R combination with
> >> emacs support? My problem is that I am so accustomed to
> >> the emacs/ess key sequences that I feel crippled when
> >> trying to run R in any other environment :-)
>
> > As a workaround :
>
> > I've been using the much less sophisticated scheme,
> > with the advantage that it has always worked on all versions of
> > Emacs and R ..
>
>
> > 1) C-u M-x R [Enter] -d gdb [Enter] # starting R with gdb in a *R* buffer
> > 2) C-g {to interrupt Emacs waiting for R's prompt .. ouch!}
> > 3) C-x b *R ... to manually switch the *R..* buffer in which
> > you now have a prompt '(gdb) '
> > 4) r # start running R
> > 5) require(...) ... ## load all R packages and R code I need
> > 6) C-c C-c (interrupt): break out of R back into gdb
> > 7) br ... ## setting breakpoints in gdb for C code
>
> > 8) r # back to running R
>
> oops! this should have been
>
> 8) c # [c]ontinue the running R ..
>
>
>
> > 9) in R, call the code that will get into calling the break
> > pointed C code
> > 10) work in the *R* buffer entering gdb commands
> > 11) "goto 8)"
>
>
> > This allows to use ESS (Emacs R interface), almost normally,
> > but of course the disadvantage is that this does not make any
> > use of the Emacs gdb interface.
>
> > We (ESS developers) could make steps 1) -- 3) more easy, notably
> > allowing ESS to also detect "(gdb) " as an R prompt which should
> > basically eliminate '2)' and '3)'.
>
> > I agree that the real solution should make Doug's original way
> > workable again, but we need someone (not me) tackle that...
I found a couple of ways around the problem. One is to start gdb with
M-x gud-gdb
which starts the old interface.
If you want to use the new graphical interface you can set first set
(setq gdb-use-separate-io-buffer nil)
then start M-x gdb on the R executable. The graphical interface still
gets a bit confused and, after "attach <R-PID>" you need to type "sig
0" or "b <position>" without a prompt. Just hitting <Enter> at that
time bombs you out of gdb because it tries to re-execute the previous
line, which was the attach.
Also, there are peculiarities with trying to get rid of the *gud*
buffer. You need to kill the buffer rather than quitting from gdb.
If you quit from gdb the buffer seems to become a zombie in that you
can't kill it.
More information about the ESS-help
mailing list