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://sourceware.org/git/archer.git src
    cd src
    git remote add gdb git://sourceware.org/git/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
    make
  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.