I would like to use pyclewn in vim in order to debug some of my C++ code. In order to make my day easier I would like to map several commands to one key, for example:
au BufNewFile,BufRead *.cxx,*.cpp,*.c noremap <F6>
\:Pyclewn <CR> :Cfile %<<CR> :Cbreak main <CR>
As stated in the manual, I need to have the async keword set, so I have
let g:pyclewn_args = "--gdb=async"
in my ~\.vimrc file. However, when pressing F6, the gdb will load the file after all the other commands like this
Pyclewn version 1.11.py2 starting a new instance of gdb.
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
(...)
(gdb) break main
No symbol table is loaded. Use the "file" command.
(gdb) file foo
Reading symbols from foo...done.
(gdb)
How can I force file foo to come before other commands in the debugger?
So, just changed to pyclewn 2.0, in which I don't have the problem any more
Related
I use GDB to understanding how CPython executes the test.py source file and I want to stop the CPython when it starts the execution of opcode I am interested.
OS: Ubuntu 18.04.2 LTS
Debugger: GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
The first problem - many CPython's .py own files are executed before my test.py gets its turn, so I can't just break at the _PyEval_EvalFrameDefault - there are many of them, so I should distinguish my file from others.
The second problem - I can't set the condition like "when the filename is equal to the test.py", because the filename is not a simple C string, it is the CPython's Unicode object, so the standard GDB string functions can't be used for comparing.
At this moment I do the next trick for breaking the execution at the needed line of test.py source:
For example, I have the source file:
x = ['a', 'b', 'c']
# I want to set the breakpoint at this line.
for e in x:
print(e)
I add the binary left shift operator to the code:
x = ['a', 'b', 'c']
# Added for breakpoint
a = 12
b = 2 << a
for e in x:
print(e)
And then, track the BINARY_LSHIFT opcode execution in the Python/ceval.c file by this GDB command:
break ceval.c:1327
I have chosen the BINARY_LSHIFT opcode, because of its seldom usage in the code. Thus, I can reach the needed part of .py file quickly - it happens once in the all other .py modules executed before my test.py.
I look the more straightforward way of doing the same, so
the questions:
Can I catch the moment the test.py starts executing? I should mention, what the test.py filename is appearing on different stages: parsing, compilation, execution. So, it also will be good to can break the CPython execution at the any stage.
Can I specify the line of the test.py, where I want to break? It is easy for .c files, but is not for .py files.
My idea would be to use a C-extension, to make setting C-breakpoints possible in a python-script (similar to pdb.set_trace() or breakpoint() since Python3.7), which I will call cbreakpoint.
Consider the following python-script:
#example.py
from cbreakpoint import cbreakpoint
cbreakpoint(breakpoint_id=1)
print("hello")
cbreakpoint(breakpoint_id=2)
It could be used as follows in gdb:
>>> gdb --args python example.py
[gdb] b cbreakpoint
[gdb] run
Now, the debuger would stops at cbreakpoint(breakpoint_id=1) and cbreakpoint(breakpoint_id=2).
Here is proof of concept, written in Cython to avoid the otherwise needed boilerplate-code:
#cbreakpoint.pyx
cdef extern from *:
"""
long long last_breakpoint_id = -1;
void cbreakpoint(long long breakpoint_id){
last_breakpoint_id = breakpoint_id;
}
"""
void c_cbreakpoint "cbreakpoint"(long long breakpoint_id)
def cbreakpoint(breakpoint_id = 0):
c_cbreakpoint(breakpoint_id)
which can be build inplace via:
cythonize -i cbreakpoint.pyx
If Cython isn't installed, I have uploaded a version which doesn't depend on Cython (too much code for this post) on github.
It is also possible to break conditionally, given the breakpoint_id, i.e.:
>>> gdb --args python example.py
[gdb] break src/cbreakpoint.c:595 if breakpoint_id == 2
[gdb] run
will break only after hello was printed - at cbreakpoint with id=2 (while cbreakpoint with id=1 will be skipped). Depending on Cython version the line can vary, but can be found out once gdb stops at cbreakpoint.
It would also do something similar without any additional modules:
add breakpoint or import pdb; pdb.set_trace() instead of cbreakpoint
gdb --args python example.py + run
When pdb interrupts the program, hit Ctrl+C in order to interrupt in gdb.
Activate breakpoints in gdb.
continue in gdb and then in pdb (i.e. c+enter twice).
A small problem is, that after that the breakpoints might be hit while in pdb, so the first method is a little bit more robust.
I am trying to debug a C++ program using GDB. I have set 15 breakpoints. Most of the breakpoints are in different files. After the first 5 breakpoints, it became difficult to remember what line of code any given breakpoint refers to.
I struggle quite a bit simply trying to recall what a given breakpoint refers to. I find this quite distracting. I was wondering if there is a way to tell gdb to display code around a certain breakpoint.
Something like this - $(gdb) code 3 shows 30 lines of code around breakpoint 3. Is this possible today. Could you please show me how?
I run gdb in tui mode, and I also keep emacs open to edit my source files.
You can use gdb within emacs.
In emacs, type M-x gdb, after entering the name of the executable, type M-x gdb-many-windows. It brings up an IDE-like interface, with access to debugger, locals, source, input/output, stack frame and breakpoints.
You can find a reference and snapshot here.
I don't think you can do it exactly like this in gdb as such, but it can be scripted in gdb python.
This crude script should help:
import gdb
class Listbreak (gdb.Command):
""" listbreak n Lists code around breakpoint """
def __init__ (self):
super(Listbreak, self).__init__ ("listbreak", gdb.COMMAND_DATA)
def invoke (self, arg, from_tty):
printed = 0
for bp in gdb.breakpoints():
if bp.number == int(arg[0]):
printed = 1
print ("Code around breakpoint " + arg[0] + " (" + bp.location + "):")
gdb.execute("list " + bp.location)
if printed == 0:
print ("No such breakpoint")
Listbreak()
Copy this to listbreak.py, source it in gdb (source listbreak.py), then use it like this:
listbreak 2
I am trying to set a breakpoint on a function but lldb gives me an error "WARNING: Unable to resolve breakpoints to any actual locations.."
Following their example over at http://lldb.llvm.org/lldb-gdb.html , I have to use breakpoint set --method xxxxxxxxx
The function where I try to set a breakpoint is called
pf::WebViewImpl::~WebViewImpl()
__ZN2pf11WebViewImplD1Ev
Which one should I use to be able to set a breakpoint?
You can put a breakpoint on your destructor using the --method option,
(lldb) br s -M ~WebViewImpl
You can use the --name option with just the dtor method name too,
(lldb) br s -n ~WebViewImpl
and lldb should find it. Finally, you can pass the mangled name to breakpoint set and that will work as well,
(lldb) br s -n _ZN2pf11WebViewImplD1Ev
Note that there's only one underscore in the mangled name - nm(1)'s output will list a leading underscore that you need to omit.
If this method is in a shared library or framework and the process hasn't launched yet, then lldb is correct in saying "Unable to resolve breakpoint to any actual locations". Once your process starts running, the framework/solib will be loaded, lldb will evaluate all breakpoints and see that it now has a valid location.
I have the following C# program (test.cs) which I want to debug:
using System;
using System.Collections.Generic;
class Program
{
static void Main(string[] args)
{
Console.WriteLine( "Hello, World!" );
List<int> list = new List<int>();
list.Add(123);
list.Add(234);
list.Add(345);
list.Add(456);
int number = 4;
++number;
Console.WriteLine(" number " + number); // <--- L:16 I want to set a breakpoint here :)
Console.WriteLine("Number of elements" + list.Count);
foreach (Object obj in list)
{
Console.WriteLine(" " + obj);
}
Console.WriteLine("Bye");
}
}
And below is the debug session using lldb and mono (I am in OSX). I can start the session and run the program however I am not able to setup any breakpoint. I guess that when using mono as the executable file things are different. How can I achieve this?
$ mcs -debug test.cs
$ lldb
(lldb) target create mono
Current executable set to 'mono' (i386).
(lldb) b test.cs:16
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) run --debug test.exe
Process 15191 launched: '/usr/bin/mono' (i386)
Hello, World!
number 5
Number of elements4
123
234
345
456
Bye
Process 15191 exited with status = 0 (0x00000000)
(lldb)
I've tried with GBD as this old guide suggests but it is worse, apparently there is something broken in mono in OSX that makes it impossible to debug unless the soft debugger is used (which is exactly what I want to avoid. MonoDevelop debugger is really really unstable/unreliable/slow). This is what I have tried with GBD. No luck at all.
And help is appreciated.
Isn't mono the interpreter for your language and test.exe the binary? lldb only knows about mono -- any breakpoints you try to set would be in the mono interpreter. e.g. if you were debugging an issue with mono itself.
This is a unique enough environment that you'll need to do a little analysis to understand what lldb sees. What do you get for
(lldb) image list test.exe
? Of course if you do
(lldb) im li mono
You'll see mono listed -- because that's a binary that lldb knows about. (you can use plain image list aka im li to see all the binaries that lldb knows)
You can ask lldb to list all of the line table entries based on a source filename with a command line
(lldb) target modules dump line-table test.cs
if lldb has any debug information for a test.cs, you'll see a line table. Without a line table, file and line breakpoints (b test.cs:16) won't work.
For what it's worth, I don't think trying to use lldb (or gdb) to debug your C# program will work. You'll probably need to use some facility of the mono runtime itself to set breakpoints and examine program state.
I am new to the idb/gdb debugger so I am apologize for the bad questions in advance. I am trying to set a breakpoint in a function called set_time_i which is in a file called time_manager.F90 by using idb. However, idb keeps giving me error message and stops me from setting hte breakpoint. May I know if I did something wrong ? I tried all these commands:
1) (idb) break time_manager.F90:set_time_i
2) (idb) break time_manager:set_time_i
3) (idb) break set_time_i
4) (idb) break time_manager_:set_time_i_
The error message is
" break time_manager:set_time_i ^ Unable to parse input as legal command or Fortran expression."
None of above work. Did I miss something when I use it ? Thanks
Unlike C, the command
break file:function
doesn't work for Fortran (be it GDB or IDB). I generally start Intel debugger in GDB mode and the 3rd form of your invocation works.
[shell] $ idbc -gdb a.out # Command-line, GDB mode
(idb) break set_time_i