Working on GDB

For future reference, and because I keep forgetting things, here is how I work on GDB:

  1. Check out a copy of the sources. Some of this is described on the branch management page of the GDB wiki:
    mkdir /somewhere/to/work
    cd /somewhere/to/work
    git clone ssh:// src
    cd src
    git remote add gdb git://
  2. Point the master branch to the correct place. The real one is in the GDB repo, but there’s an old one in Archer that is no longer used. Open /somewhere/to/work/src/.git/config in your favourite editor and change remote = origin to remote = gdb in the [branch "master"] section. Then probably do a git pull to fetch the actual code you’ll be working on.
  3. Create yourself a nice new branch to make your changes in:
  4. git branch --track archer-gbenson-lazy-skip-inline-frames gdb/master
    git checkout archer-gbenson-lazy-skip-inline-frames
  5. (make your changes here)
  6. Build it. I build out-of-tree, like this:
    mkdir /somewhere/to/work/build
    cd /somewhere/to/work/build
    CFLAGS="-g -O0" ../src/configure --with-separate-debug-dir=/usr/lib/debug
  7. Run the testsuite. I like to run the tests twice, once without and once with the changes, then I diff the results and pipe it through a script I wrote to hide the unimportant bits:
    make check >& build-20110921-3.log
    diff -u baseline-20110919.log build-20110921-3.log | gdbtestdiff
  8. If a test fails, you’ll want to hook gdb into it. To do that you run the specific test to create a transcript:
    cd /somewhere/to/work/build/gdb/testsuite
    runtest TRANSCRIPT=1 ../../../src/gdb/testsuite/gdb.opt/inline-cmds.exp
    gdb ../gdb
  9. Then you pipe the transcript into gdb:
    set prompt (top-gdb) 
    b internal_error
    r -nx <transcript.1

Ok, I think that is enough for now.