91 lines
3.7 KiB
Markdown
91 lines
3.7 KiB
Markdown
---
|
|
date: 2011-11-29T00:00:00-05:00
|
|
title: "My workflow with GDB and git -- part 1"
|
|
tags: [gdb, workflow, git, fedora-planet, en_us, english, free-software]
|
|
---
|
|
|
|
This post is actually a "reply" to Gary Benson's [Working on
|
|
gdb](http://gbenson.net/?p=292) post.
|
|
|
|
I have been working with [GDB](http://www.gnu.org/s/gdb/) for quite some
|
|
time now, and even though the project officially uses
|
|
[CVS](http://en.wikipedia.org/wiki/Concurrent_Versions_System) (yes, you
|
|
read it correctly, it is **CVS** indeed!) as its version control system,
|
|
fortunately we also have a
|
|
[git](http://en.wikipedia.org/wiki/Git_%28software%29) mirror. In the
|
|
end, what happens is that almost every developer uses the git mirror and
|
|
just goes to CVS to commit something. But this is another discussion.
|
|
Aside of this git mirror, we also have the
|
|
[Archer](http://sourceware.org/gdb/wiki/ProjectArcher) repository (which
|
|
uses git by default).
|
|
|
|
My plan here is to show you how I do my daily work with GDB. The
|
|
workflow is pretty simple, but maybe you will see something here that
|
|
might help you.
|
|
|
|
Checking out the code
|
|
---------------------
|
|
|
|
The first thing to do is to check out the code. I only have one GDB
|
|
repository here, and I make branches out of it whenever I want to hack.
|
|
So, to check out (or *clone*, in git's parlance) the code, I do (or
|
|
did):
|
|
|
|
With this, we have just cloned the GDB repository, and also added
|
|
another remote (i.e., repository). This is useful because we might want
|
|
to hack on a branch which is on Archer, but use GDB's **master** branch
|
|
as a base.
|
|
|
|
Create a new branch for your work
|
|
---------------------------------
|
|
|
|
So, now it's time to create a new branch for you. Here I use one of my
|
|
little "tricks" (taught to me by my friend
|
|
[Dodji](http://dodji.seketeli.net/)), which is the command
|
|
`git-new-workdir`. This is a nice command because it creates a new
|
|
working directory for your project!
|
|
|
|
Maybe you're wondering why this is so cool. Well, if you ever worked
|
|
with git, and more specifically, if you ever used more than one branch
|
|
at a time, then maybe you will understand my excitement. In this
|
|
scenario, having to constantly switch between the branches is not
|
|
something rare. When you have uncommited work in your tree you can
|
|
always use `git stash`, but that is not the ideal solution (for me).
|
|
Sometimes I would forget what was on the stash, and later when I checked
|
|
it, it was full of crap. Also, I like to have a separate directory for
|
|
every project I am working on.
|
|
|
|
It is also important to mention that `git-new-workdir` is under the
|
|
directory `/usr/share/doc/git-VERSION/contrib/workdir/`, so I created an
|
|
alias that will automagically call the script for me:
|
|
|
|
So, after setting up the script, here is what I do:
|
|
|
|
Build GDB
|
|
---------
|
|
|
|
In order to build the project, I create a `build-64` directory inside my
|
|
project directory (which, in the example above, is
|
|
`work/lazy-debuginfo-reading`).
|
|
|
|
GDB fortunately supports VPATH building (i.e., build the project outside
|
|
of the source tree). I strongly recommend you to use it.
|
|
|
|
As you may have noticed, I use `-g3` (include debuginfo) and `-O0` (do
|
|
not optimize the code) in `CFLAGS`. Also, since some of the features I
|
|
work on may affect code in other architectures, I use
|
|
`--enable-targets=all`. It will tell configure to compile everything
|
|
related to all architectures (not only `x86_64`, for example). At last,
|
|
I specify a separate debug directory which GDB should use to search for
|
|
debuginfo files.
|
|
|
|
Finalizing (for now)
|
|
--------------------
|
|
|
|
After that, you will have a fresh GDB binary compiled in the `build-64`
|
|
directory. But that is not enough yet, since you will also want to test
|
|
GDB and make sure you didn't insert a bug while hacking on it. In my
|
|
next post, I will explain what is my "testflow". I hope it will be
|
|
useful for someone :-).
|
|
|
|
Stay tuned!
|