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:

git branch --track archer-gbenson-lazy-skip-inline-frames gdb/master
git checkout archer-gbenson-lazy-skip-inline-frames

4. (make your changes here)
5. 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

6. 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

7. 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

8. 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.