I would like to debug simple F* program using Emacs fstar-mode and gdb. At the very end of the wiki of fstar-mode https://github.com/FStarLang/fstar-mode.el is information:
The fstar-gdb command (M-x) attaches GDB to the current F* process and launches Emacs' GDB-mi interface
with no further explanation.
When in Emacs (lets assume I am editing Test.fst file) I invoke fstar-gdb command and proceed to gdb console I am trying to use commands file Test and run. They are working correctly, however break 3 (or any other line) says that it failed to find line 3 in main.c (obviously).
How do I use gdb with F*?
The fstar-gdb command is intended to the debug F* compiler itself, not programs compiled with F*.
For F* programs, the best would likely be:
ocamldebug if you're using the byte-compiler
the usual procedure for GDB debugging of OCaml programs (see https://ocaml.org/meetings/ocaml/2012/slides/oud2012-paper5-slides.pdf; this is because most F* programs are extracted to OCaml before being compiled).
the usual procedure for debugging GDB debugging of C programs if you're using Low*.
Related
I was attempting to debug a MEX file (made with the -g flag). I'm on MATLAB R2016B working under MinGW64.
I don't have access to either Visual Studio 2012 nor Eclipse, so using either of those to debug wasn't possible.
So, instead, I was following this guide: https://www.mathworks.com/help/matlab/matlab_external/debugging-on-linux-platforms.html
Which explains how to do it with gdb.
However, the moment I do matlab -Dgdb in my terminal, it just starts up the MATLAB application, with no gdb prompt in either my terminal or in MATLAB.
Did they skip a step in those instructions, or is there something obvious I missed?
EDIT: If I go against what they suggest and start gdb first by calling gdb matlab, then do r -Dgdb and then follow the instructions from that point, I end up getting that "dbmex doesn't work on the PC. See the MATLAB External Interfaces Guide for details on how to debug MEX-files."
I'm using GDB 8.0.1 on Mac OS High Sierra 10.13.3. Basically, doing:
(gdb) r < some_input_file.in
ignores the input file. It acts as if the command ran was simply
(gdb) r
The closest thread I found about this problem was Input redirection from file gdb but no solution was posted.
Any clues?
Thanks!
You are probably running into an interaction between gdb and macOS SIP ("System Integrity Protection").
gdb implements run redirections by passing the command line to the shell; then it waits for the shell to invoke your program before starting to "really debug". The shell is actually still controlled by gdb using ptrace -- gdb uses this to observe the eventual exec and to ensure that your process is also traced.
However, SIP prevents certain programs from being traced, and in particular programs in /usr/bin, like most shells. This causes run to stop working entirely, because the shell can't be started.
So, to make gdb continue to work, users often set startup-with-shell off. Perhaps whatever gdb build you are using does this by default (or maybe, like me, you put this in your .gdbinit and forgot about it). This setting lets run work -- but at the cost of disabling redirections.
There's a gdb bug for this which you can follow.
I have a program that I'd like to debug with gdb via emacs. In order to run development versions of this program, I have a shell script that I can source that sets up the calling environment to see the right libraries, etc. What I can't sort out is how to ask emacs/gud to source this file before executing gdb.
I've tried using a command like "source env.sourceme && gdb my_program", but emacs complains that it doesn't know what "source" means. I guess it's not really running gdb in a shell, so these kinds of tricks won't work.
So, how can I convince gud/emacs/whatever to run gdb in my custom environment? I've got a hacky solution in place, but I feel like I must be missing something.
gdb has its own syntax for setting environment variables:
set environment varname [=value]
Instead of a shell script, write your variable definitions in a file using the above syntax, then source the file from a running gdb session. Note that this is not bash's built-in source command, but gdb's own, so naturally bash-style environment variable definitions will not work.
What's your hacky solution?
Why wouldn't you just have a wrapper script that sources env.sourceme and then run gdb?
#!/usr/bin/env bash
source env.sourceme
gdb -i=mi $1
You can modify the Emacs environment using setenv, either interactively (M-x setenv) or programmatically:
(setenv "FOOBAR" "whatever")
When you run gud-gdb, whatever you set using setenv will be passed to the gdb process.
I'm trying to use gdb with emacs. The library that I'm trying to debug is loaded by a process and can't be run directly. Hence I attach to the process by using the attach command inside gdb. Attaching to a process and setting breakpoints works fine when I use gdb from a shell, but when I use gdb in emacs (by pressing M-x gdb or M-x gud-gdb), it can't set breakpoints. It shows me an error which says "Can't access memory at 0x7efb04". I'm using emacs 23.1.1.
Here is a breakdown of the process I follow:
Press M-x gdb or M-x gud-gdb to launch gdb inside emacs.
Enter the name of the executable built with debugging symbols.
Type "attach [PID]" to attach gdb to a running process.
Set a breakpoint by typing: filename:line number.
The last step gives me an error which says "Can't access memory at 0x7efb04".
Any ideas why this is happening?
EDIT : I get the same error when using DDD (UI for GDB). So I guess it's not an emacs specific issue.
Have you compiled with debug-information? Do you have some code which shows the problem?
Does this happen in other IDEs also?
I figured it out. The problem is with step 2. Entering the name of the executable built with debugging symbol causes the problem. Instead, just launching GDB and attaching to process works fine. I'm not sure if this is the expected behavior.
In DDD, the executable with debugging symbols has to be opened first before we can attach to process. I don't know how to get around that in DDD.
After installing emacs and attempting to run-lisp, I get
Searching for program: No such file or directory, lisp
Then, after trying to run lisp again, a new inferior-lisp buffer opens, but if I try entering anything in, I get:
Output file descriptor of inferior-lisp<1> is closed
Any idea what I should do?
You should set inferior-lisp-program variable. Be careful 'cos some Lisps expect the core to be specified in the command-line or reside in a current directory (especially if you're on Windows).
If you're a newbie and just want to get familiar with lisp there is a built-in Elisp interpreter. Run M-x ielm to get it.
From the info page on emacs (31.11 Running an External Lisp):
To run an inferior Lisp process, type M-x run-lisp'. This runs the
program namedlisp', the same program you would run by typing lisp'
as a shell command, with both input and output going through an Emacs
buffer namedlisp'.
It look like you do not have an program in your path that is call "lisp".