Line by line debugging in linux

Dynamic debug¶

Introduction¶

This document describes how to use the dynamic debug (dyndbg) feature.

Dynamic debug is designed to allow you to dynamically enable/disable kernel code to obtain additional kernel information. Currently, if CONFIG_DYNAMIC_DEBUG is set, then all pr_debug() / dev_dbg() and print_hex_dump_debug() / print_hex_dump_bytes() calls can be dynamically enabled per-callsite.

If CONFIG_DYNAMIC_DEBUG is not set, print_hex_dump_debug() is just shortcut for print_hex_dump(KERN_DEBUG) .

For print_hex_dump_debug() / print_hex_dump_bytes() , format string is its prefix_str argument, if it is constant string; or hexdump in case prefix_str is build dynamically.

Dynamic debug has even more useful features:

• Simple query language allows turning on and off debugging statements by matching any combination of 0 or 1 of:
  • source filename
  • function name
  • line number (including ranges of line numbers)
  • module name
  • format string
• Provides a debugfs control file: /dynamic_debug/control which can be read to display the complete list of known debug statements, to help guide you

Controlling dynamic debug Behaviour¶

The behaviour of pr_debug() / dev_dbg() are controlled via writing to a control file in the ‘debugfs’ filesystem. Thus, you must first mount the debugfs filesystem, in order to make use of this feature. Subsequently, we refer to the control file as: /dynamic_debug/control . For example, if you want to enable printing from source file svcsock.c , line 1603 you simply do:

If you make a mistake with the syntax, the write will fail thus:

Viewing Dynamic Debug Behaviour¶

You can view the currently configured behaviour of all the debug statements via:

You can also apply standard Unix text manipulation filters to this data, e.g.:

The third column shows the currently enabled flags for each debug statement callsite (see below for definitions of the flags). The default value, with no flags enabled, is =_ . So you can view all the debug statement callsites with any non-default flags:

Command Language Reference¶

At the lexical level, a command comprises a sequence of words separated by spaces or tabs. So these are all equivalent:

Command submissions are bounded by a write() system call. Multiple commands can be written together, separated by ; or \n :

If your query set is big, you can batch them too:

A another way is to use wildcard. The match rule support * (matches zero or more characters) and ? (matches exactly one character).For example, you can match all usb drivers:

At the syntactical level, a command comprises a sequence of match specifications, followed by a flags change specification:

The match-spec’s are used to choose a subset of the known pr_debug() callsites to which to apply the flags-spec. Think of them as a query with implicit ANDs between each pair. Note that an empty list of match-specs will select all debug statement callsites.

A match specification comprises a keyword, which controls the attribute of the callsite to be compared, and a value to compare against. Possible keywords are::

line-range cannot contain space, e.g. “1-30” is valid range but “1 — 30” is not.

The meanings of each keyword are:

The given string is compared against the function name of each callsite. Example:

The given string is compared against either the full pathname, the src-root relative pathname, or the basename of the source file of each callsite. Examples:

The given string is compared against the module name of each callsite. The module name is the string as seen in lsmod , i.e. without the directory or the .ko suffix and with — changed to _ . Examples:

The given string is searched for in the dynamic debug format string. Note that the string does not need to match the entire format, only some part. Whitespace and other special characters can be escaped using C octal character escape \ooo notation, e.g. the space character is \040 . Alternatively, the string can be enclosed in double quote characters ( » ) or single quote characters ( ‘ ). Examples:

The given line number or range of line numbers is compared against the line number of each pr_debug() callsite. A single line number matches the callsite line number exactly. A range of line numbers matches any callsite between the first and last line number inclusive. An empty first number means the first line in the file, an empty line number means the last number in the file. Examples:

The flags specification comprises a change operation followed by one or more flag characters. The change operation is one of the characters:

For print_hex_dump_debug() and print_hex_dump_bytes() , only p flag have meaning, other flags ignored.

For display, the flags are preceded by = (mnemonic: what the flags are currently equal to).

Note the regexp ^[-+=][flmpt_]+$ matches a flags specification. To clear all flags at once, use =_ or -flmpt .

Debug messages during Boot Process¶

To activate debug messages for core code and built-in modules during the boot process, even before userspace and debugfs exists, use dyndbg=»QUERY» , module.dyndbg=»QUERY» , or ddebug_query=»QUERY» ( ddebug_query is obsoleted by dyndbg , and deprecated). QUERY follows the syntax described above, but must not exceed 1023 characters. Your bootloader may impose lower limits.

These dyndbg params are processed just after the ddebug tables are processed, as part of the arch_initcall. Thus you can enable debug messages in all code run after this arch_initcall via this boot parameter.

On an x86 system for example ACPI enablement is a subsys_initcall and:

will show early Embedded Controller transactions during ACPI setup if your machine (typically a laptop) has an Embedded Controller. PCI (or other devices) initialization also is a hot candidate for using this boot parameter for debugging purposes.

If foo module is not built-in, foo.dyndbg will still be processed at boot time, without effect, but will be reprocessed when module is loaded later. dyndbg_query= and bare dyndbg= are only processed at boot.

Debug Messages at Module Initialization Time¶

When modprobe foo is called, modprobe scans /proc/cmdline for foo.params , strips foo. , and passes them to the kernel along with params given in modprobe args or /etc/modprob.d/*.conf files, in the following order:

parameters given via /etc/modprobe.d/*.conf :

foo.dyndbg as given in boot args, foo. is stripped and passed:

args to modprobe:

These dyndbg queries are applied in order, with last having final say. This allows boot args to override or modify those from /etc/modprobe.d (sensible, since 1 is system wide, 2 is kernel or boot specific), and modprobe args to override both.

In the foo.dyndbg=»QUERY» form, the query must exclude module foo . foo is extracted from the param-name, and applied to each query in QUERY , and only 1 match-spec of each type is allowed.

The dyndbg option is a “fake” module parameter, which means:

• modules do not need to define it explicitly
• every module gets it tacitly, whether they use pr_debug or not
• it doesn’t appear in /sys/module/$module/parameters/ To see it, grep the control file, or inspect /proc/cmdline.

For CONFIG_DYNAMIC_DEBUG kernels, any settings given at boot-time (or enabled by -DDEBUG flag during compilation) can be disabled later via the sysfs interface if the debug messages are no longer needed:

Источник

How to run a Linux program line by line

I would like to run a GTK+/C program line by line with some debugger. I have never debugged a Linux program so where can I find instructions to a very beginner on how to debug code? I have just an idea that I have to download the sources from net, compile the project with debug symbols and run sources through DDD or GDB. So can anyone give suggestions how to start studying these subjects and what could be a good debugger to start? I have at least time to learn things.

3 Answers 3

Also look into nemiver besides DDD, they are good at different things but nemiver is coming along very nicely.

PS. If you’re on Ubuntu and you want to step through an application that’s installed from the package repository, let’s called it some_package, then do this:

1. install the packages «build-essential» and «devscripts»
2. run «sudo apt-get build-dep some_package» to install all things needed to compile that package
3. run «mkdir -p

/src/some_package» to create a directory for the source code

Go into System::Administration::Software Sources and activate the «Source Code» repository

run «apt-get source some_package» to download the source code for some_package and put it in the current directory

use «cd» to move into the specific app directory, usually something like «some-app-1.2.3»

7A. run «debuild -us -uc -b» to compile the source into a fresh installable .DEB file compiled in release mode WITHOUT debug information

or (and this is the central part):

7B. run «MAKEFLAGS=-j6 DEB_BUILD_OPTIONS=»nostrip noopt parallel=5″ CFLAGS=»-g3 -O0″ debuild -us -uc» to build a deb in debug mode WITH debug information

1. use «cd ..» to move up one step and then do «ls» and you should see the generated DEB files (multiple binary packages, i.e. DEBs, can be generated from a single source package)
2. sudo «sudo dpkg -i some_package_123.deb» to install the version you just built

Of course, you could optionally modify the code between steps 6 and 7. The nice thing about this method is that it works for pretty much any application. You can use it for Firefox, the Linux kernel, the mesa stack or whatever.

Источник

Line by line c — c++ code debugging in Linux ubuntu [closed]

Want to improve this question? Update the question so it’s on-topic for Stack Overflow.

Closed 7 years ago .

I am coding using gedit in ubuntu and running program in terminal. While working in windows using Turboc or netbeans we can debug code line by line. How can we do it in ubuntu terminal? or any other option?

Answers

gdb (The Gnu debugger) is best choice

apt-get install gdb

man gdb

man gdb will give more info

All useful gdb commands and an example with simple cpp program are given Here

What happens when a core file is generated from a Linux distro other than the one we are running in Dev? Is the stack trace even meaningful?

It the executable is dynamically linked, as yours is, the stack GDB produces will (most likely) not be meaningful.

The reason: GDB knows that your executable crashed by calling something in libc.so.6 at address 0x00454ff1 , but it doesn’t know what code was at that address. So it looks into your copy of libc.so.6 and discovers that this is in select , so it prints that.

But the chances that 0x00454ff1 is also in select in your customers copy of libc.so.6 are quite small. Most likely the customer had some other procedure at that address, perhaps abort .

You can use disas select , and observe that 0x00454ff1 is either in the middle of instruction, or that the previous instruction is not a CALL . If either of these holds, your stack trace is meaningless.

You can however help yourself: you just need to get a copy of all libraries that are listed in (gdb) info shared from the customer system. Have the customer tar them up with e.g.

Then, on your system:

We then advice the Customer to run a -g binary so it becomes easier to debug.

A much better approach is:

• build with -g -O2 -o myexe.dbg
• strip -g myexe.dbg -o myexe
• distribute myexe to customers
• when a customer gets a core , use myexe.dbg to debug it

You’ll have full symbolic info (file/line, local variables), without having to ship a special binary to the customer, and without revealing too many details about your sources.

As I said in my comment above, the specs are not clear but I suspect this is what you are trying to do. Here’s a way to load data into Oracle using sqlldr where a field is surrounded by double-quotes and contains linefeeds where the end of the record is a combination carriage return/linefeed. This can happen when the data comes from an Excel spreadsheet saved as a .csv for example, where the cell contains the linefeeds.

Here’s the data file as exported by Excel as a .csv and viewed in gvim, with the option turned on to show control characters. You can see the linefeeds as the ‘$’ character and the carriage returns as the ‘^M’ character:

Construct the control file like this using the «str» clause on the infile option line to set the end of record character. It tells sqlldr that hex 0D (carriage return, or ^M) is the record separator (this way it will ignore the linefeeds inside the double-quotes):

After loading, the data looks like this with linefeeds in the comment field (I called it colc) preserved:

I found out how to debug the C++ part while running python. (realized it while reading about process ID detection in Python book..).
First you run the python program which includes C++ programs. At the start of the python program, use raw_input() to make the program wait for you input. But just before that do print os.getpid() (of course you should have imported os package). When you run the python program, it will have printed the pid of the python program you are running and will be waiting for your keyboard input.

python stop code :

Or, you can use import pdb, pdb.set_trace() as comment below.(thanks @AndyG) and see EDIT* to get pid using ps -aux .

Now, suppose the C++ shared library is _caffe.so (which is my case. This _caffe.so library has all the C++ codes and boost python wrapper functions). 27352 is the pid. Then in another shell start gdb like

or if you want to use graphical debugging using like DDD, do

Then you’ll see gdb starts and wait with prompt. The python program is interrupted by gdb and waits in stopped mode (it was waiting for your key input but now it’s really in stopeed mode, and it needs gdb continue command from the second debugger to proceed with the key waiting).
Now you can give break point command in gdb like

and you can see message like

When you give continue command in the second gdb window(that was holding the program), the python code runs again. Of course you should give a key input in the first gdb window to make it proceed.
Now at least you can debug the C++ code while running python program(that’s what I wanted to do)!

I later checked if I can do python and C++ debugging at the same time and it works. You start the debugger(DDD) like ddd -pydb prog1.py options.. and attach another DDD using method explained above. Now you can set breakpoints for python and C++ and using other debug functions in each window(I wish I had known this a couple of months earlier.. It should have helped tons.).

EDIT : to get the pid, you can do ps -aux | grep python instead. This pid is the next of ddd’s pid.

Источник