Difference between revisions of "Debugging Makefiles"

From eLinux.org
Jump to: navigation, search
(create page)
 
(Add Category Tips and Tricks, Development Tools)
 
(13 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
Here is some information on debugging Makefiles:
 
Here is some information on debugging Makefiles:
  
 +
== showing symbol values, and showing file dependencies ==
 
There's a good Dr. Dobbs article on this topic, by John Graham-Cumming, at:
 
There's a good Dr. Dobbs article on this topic, by John Graham-Cumming, at:
 
* [http://www.ddj.com/development-tools/197003338 Debugging Makefiles]
 
* [http://www.ddj.com/development-tools/197003338 Debugging Makefiles]
Line 6: Line 7:
 
http://www.embedded.com/columns/technicalinsights/197003517?printable=true
 
http://www.embedded.com/columns/technicalinsights/197003517?printable=true
  
 +
This article describes some macros you can put in your Makefiles to show
 +
you the values of symbols, and to show the dependencies that led to a particular
 +
target being built.  This is handy if you have a complex Makefile that you
 +
are trying to debug.
 +
 +
== Makefile Debugger ==
 
John has also written a Makefile Debugger.
 
John has also written a Makefile Debugger.
The following resources are needed to use this debugger:
+
 
 +
The following articles describe the debugger and how to use it:
 +
* [http://www.cmcrossroads.com/content/view/6479/120/ An Interactive GNU Make Debugger]
 +
* [http://www.cmcrossroads.com/content/view/6529/120/ Dynamic Breakpoints in the GNU Make Debugger]
 +
 
 +
The following resources are needed to use the debugger:
  
 
* Download gmsl (a library of gnu make stuff), from http://gmsl.sf.net/
 
* Download gmsl (a library of gnu make stuff), from http://gmsl.sf.net/
 
* Download gmd (the debugger itself), from http://gmd.sf.net/
 
* Download gmd (the debugger itself), from http://gmd.sf.net/
  
Explode the tarballs from these, and place __gmsl, gmsl and gmd in the
+
Expand the tarballs from these, and place __gmsl, gmsl and gmd in the
 
directory with the Makefile you wish to debug.
 
directory with the Makefile you wish to debug.
  
 
Add the following lines to your Makefile:
 
Add the following lines to your Makefile:
  include gdm
+
  include gmd
  
 
and
 
and
Line 23: Line 35:
 
         $(__BREAKPOINT)
 
         $(__BREAKPOINT)
  
See the following articles for more information:
+
== remake ==
* [http://www.cmcrossroads.com/content/view/6479/120/ An Interactive GNU Make Debugger]
+
''remake'' is a patched GNU make with a debugger,
* [http://www.cmcrossroads.com/content/view/6529/120/ Dynamic Breakpoints in the GNU Make Debugger]
+
better tracing and error reporting. The latest version is based on GNU make version 3.82 released sources.
 +
 
 +
See: http://bashdb.sourceforge.net/remake/
 +
 
 +
Use the option ''--debugger'' (short form is ''-X'') in your make invocation. For example:  
 +
 
 +
$ remake --debugger
 +
 
 +
But much of the time you may be able to get by using just the better tracing that is given.
 +
For that use option ''--trace'' (short form is ''-x''). For example:
 +
 
 +
$ remake -x
 +
 
 +
== Debugging a kernel build ==
 +
=== Verbose options ===
 +
There are several Kernel makefile tricks which are helpful for debugging a kernel build.
 +
 
 +
Try "make V=1 [<rest of make args...>]" to see all the full-length commands used to build the kernel.
 +
 
 +
Sometimes, if a particular step is breaking and you don't understand why, you can copy-and-paste from
 +
this verbose command output (to the shell command line).  To do this you need to make sure you are in
 +
the correct source directory, and that all required files are present.
 +
 
 +
To see why a particular target is being build, use "make V=2".
 +
This is quite useful when a small change results in much more being build than you expected.
 +
 
 +
=== Building in a separate directory ===
 +
Use the variable KBUILD_OUTPUT either as an environment variable or on the make command line, if you wish
 +
to put the build output into a separate directory from the source.  This can be useful for several reasons, including
 +
when you want to build for multiple architectures from the same source, or when you wish to avoid cluttering up
 +
the source tree with object files, libraries and other generated files (to make diffs easier).
 +
 
 +
[[Category:Development Tools]]
 +
[[Category:Tips and Tricks]]

Latest revision as of 14:21, 11 May 2011

Here is some information on debugging Makefiles:

showing symbol values, and showing file dependencies

There's a good Dr. Dobbs article on this topic, by John Graham-Cumming, at:

or printable, all-in-one page, at http://www.embedded.com/columns/technicalinsights/197003517?printable=true

This article describes some macros you can put in your Makefiles to show you the values of symbols, and to show the dependencies that led to a particular target being built. This is handy if you have a complex Makefile that you are trying to debug.

Makefile Debugger

John has also written a Makefile Debugger.

The following articles describe the debugger and how to use it:

The following resources are needed to use the debugger:

Expand the tarballs from these, and place __gmsl, gmsl and gmd in the directory with the Makefile you wish to debug.

Add the following lines to your Makefile:

include gmd

and

all:
        $(__BREAKPOINT)

remake

remake is a patched GNU make with a debugger, better tracing and error reporting. The latest version is based on GNU make version 3.82 released sources.

See: http://bashdb.sourceforge.net/remake/

Use the option --debugger (short form is -X) in your make invocation. For example:

$ remake --debugger

But much of the time you may be able to get by using just the better tracing that is given. For that use option --trace (short form is -x). For example:

$ remake -x

Debugging a kernel build

Verbose options

There are several Kernel makefile tricks which are helpful for debugging a kernel build.

Try "make V=1 [<rest of make args...>]" to see all the full-length commands used to build the kernel.

Sometimes, if a particular step is breaking and you don't understand why, you can copy-and-paste from this verbose command output (to the shell command line). To do this you need to make sure you are in the correct source directory, and that all required files are present.

To see why a particular target is being build, use "make V=2". This is quite useful when a small change results in much more being build than you expected.

Building in a separate directory

Use the variable KBUILD_OUTPUT either as an environment variable or on the make command line, if you wish to put the build output into a separate directory from the source. This can be useful for several reasons, including when you want to build for multiple architectures from the same source, or when you wish to avoid cluttering up the source tree with object files, libraries and other generated files (to make diffs easier).