When running GDB, the debugger would print the current line it's at to give you an indication of where it's currently at.
Seeing as I'm on Mavericks, GDB doesn't seem to be an option, and as such I'm forced to use LLDB. My question is: How do I get similar behaviour from LLDB?
Currently all it does is print 7 or-so lines of code with an arrow pointing at the current line, rather than just printing the line it's on, which is rather cluttered to look at. LLDB also seems to ignore all output produced by printf
Is there a way to achieve the same, or similar results using LLDB?
I don't think the question you asked is exactly what you intended. I assume you mean "How to get LLDB to print ONLY the current line" since, as you noted, it always prints the current line along with some lines of context.
Anyway, how many lines of source get printed when you stop is controlled by the two settings:
stop-line-count-after -- The number of sources lines to display that come after the current source line when displaying a stopped context.
stop-line-count-before -- The number of sources lines to display that come before the current source line when displaying a stopped context.
Actually these aren't quite right, since setting both to 0 shows no source lines, but setting "after" to 1 shows TWO stop lines. Somebody apparently wanted to make it possible to show NO source lines, but didn't want to add an extra setting.
Anyway, you can't get just one line, but you can get it down to two.
Related
I'm trying to pass arguments to my Xcode C++ command-line tool. I think I'm following the help, and the answers I've found on Stack Overflow, but I'm not having any luck.
I'm using Xcode 7.2.1. I've edited the scheme to have two command-line arguments (an input file and an output file.) I've posted a screen shot of the editor below.
When I run the code, it doesn't find the arguments. (I don't mean that it can't find the files on disk. The program aborts because argc is 1 instead of 3.)
Can you tell me what I'm doing wrong?
EDIT: After playing around with it in response to the advice I received, it suddenly worked. I have no idea what changed. It works now with the dialog looking exactly like the screenshot I posted originally.
I'd suggest that you use only one argument set at a time. Each one of the checked lines represents a command line, not a single argument, so put both of your arguments on a single line, as in
$PROJECT_DIR/detroit.txt $PROJECT_DIR/detroit.out
I want to achieve the following:
I have a program which generates files, and it should print a warning if the file with the given name already exists, asking the user if it should be overridden. It looks like the following:
Processing file test.sdf
Checking SDF file... [OK]
Parsing SDF... [OK]
Generating NDDL model file... [WARN]
Warning. The file "/home/chris/models/test-model.nddl" already exists. Overwrite? [y/N]
Now, if the user decides what to do, I want to rewind the console cursor to the [ character of [WARN], and overwrite it with [OK] or [FAIL], and then overwrite the following lines with the next outputs of the program.
I found that I could achieve this with ANSI control sequences. Since I am just using Ubuntu I'm okay with that.
I came up with two ideas:
1) Rewind the cursor until I find the string [WARN] and then begin to write again.
2) Move the cursor up line by line until the line Generating NDDL model file... [WARN] is removed, and overwrite it with for example Generating NDDL model file... [FAIL].
But with both approaches I have a problem which I just cannot solve or find a way googling...
Problem with 1): I can't figure out how to read the character at the current cursor position. But anyway, I don't think that this would be a good idea. It just doesn't seem to be reliable.
Problem with 2): Since the path of the input file can be arbitrary, I have no control over the amount of lines which have been printed after the [WARN] appears, so I just don't know how much std::cout << "\033[F" << "\033[2K" << std::flush; I should run (ANSI Control Sequences for move-cursor-one-line-up and clear-all-contents-in-line). Also, I don't know how big the width of the terminal window is, so I can't calculate it either (no idea if this would be a good idea though...)
I am sure that there must be a way to achieve this, but I just can't figure out a good and reliable way to do so...
Does anybody of you got an idea? I appreciate every kind of help
X/Y Problem
If you insist on manipulating the console directly, then why not just back over the entire last two lines completely? Why try and edit a line when you can just reprint the entire thing. Also you are not guaranteed to be able to manipulate every console the same way between platform and shells.
You are printing the lines out you should easily know how many to back up and overwrite. If you can't do that, just clear the screen and write everything back out again.
Solution
The correct way to present an interface like this is with acurses library ( or equivalent ) and control the output to the console completely. That gives you complete control.
If you think this is overkill then you are just doomed to recreate the functionality of curses a bit of a time and end up with a mess at the end.
Well, there are some possibilites using the carriage return (\r), which will take you to the start of the current line, or by using the backspace (\b), which will rewind one character position and then you just have to write all over again. No curses. No ANSI crazyness.
I have a source file in my project, which has more than 65,536 code lines (112,444 to be exact). I'm using an "sqlite amalgamation", which comes in a single huge source file.
I'm using MSVC 2005. The problems arrives during debugging. Everything compiles and links ok. But then when I'm trying to step into a function with the debugger - it shows an incorrect code line.
What's interesting is that the difference between the correct line number and the one the debugger shows is exactly 65536. This makes me suspect (almost be sure in) some unsigned short overflow.
I also suspect that it's not a bug in the MSVC itself. Perhaps it's the limitation of the debug information format. That is, the debug information format used by MSVC stores the line numbers as 2-byte shorts.
Is there anything can be done about this (apart from cutting the huge file into several smaller ones) ?
According to a MS moderator, this is a known issue with the debugger only (the compiler seems to handle it fine as you pointed out). There is apparently no workaround, other than using shorter source files. See official response to very similar question here
Well, when I wanted to look at how sqlite works, I took the last 60000 or so lines, moved them to another file and then #include'd it. That was easy and did the trick for me. Also, if you do that, be careful not to split inside #ifdef .
If you look at the documentation for the symbolic debugging info, you will see the type used for line numbers. For example, both line and column parameters for IDiaSession::findLinesByLinenum are of type DWORD.
Edit: As #valdo points out, that still doesn't mean the debugger works properly with huge line numbers. So you have to use shorter files. It is unfortunate that such limitation exists, but even if there wasn't I'd still recommend you split your source.
Have you looked into using WinDBG instead? It's pretty capable as the Windows team use it for debugging the O/S and there's some biiiig files in there, or at least there was when I last looked.
For anyone having issues with incorrect line numbers for files < 65536 lines: I found my issue was because of inconsistent line endings in the source file. There were 129 \r newlines where the rest of the file was \r\n style. The difference between the debugger line and the correct line was 129 as well.
Unless you are modifying SQLite, you should just trust that it is doing its job. No need to step in at all. SQLite is run through a large battery of tests before release.
while debugging a C++ program with GDB, is it possible somehow to add comments to the original souce code whitout affecting to the debugging process?
I started to debug with GDB, but if I modify (just adding comments at the end of each C++ code line wiht //) the code, when I display the code in GDB I get weird display.
Thanks
Adding inline comments on existing lines should not pose a problem.
Adding new comments will break the existing line order (since debug symbols are per line number), giving you a shifted line display while debugging.
GDB, at least as it's configured by default on my Ubuntu 9.04 box, doesn't handle multi-line statements well. When I'm stepping through code, GDB only displays the last line of the current statement, even if that statement spans multiple lines.
I'm aware that I could use DDD or emacs as a frontend for GDB, but I'd prefer to solve this problem within GDB, if that's possible.
Does anyone know if there's a way to get GDB to do the right thing here?
How about running GDB with the text user interface?
gdb -tui
It makes a world of difference to the ease of use of GDB.
I'm afraid the answer is "no, there is no way to get gdb to do what you want".
The line info in the symbol tables associates each code instruction with a single
source line (not a source statement). gdb has no way of knowing that several
source lines are associated with the same source statement.