Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: gdb-patches@sourceware.org
Cc: Simon Marchi <simark@simark.ca>,
	Joel Brobecker <brobecker@adacore.com>,
	Andrew Burgess <andrew.burgess@embecosm.com>
Subject: [PATCH 2/2] Add git sha information to the gdb version string
Date: Fri, 27 Mar 2020 12:27:12 +0000	[thread overview]
Message-ID: <16599d81be47851f9ce53d7da037d9a1cdeba490.1585311874.git.andrew.burgess@embecosm.com> (raw)
In-Reply-To: <cover.1585311874.git.andrew.burgess@embecosm.com>
In-Reply-To: <cover.1585311874.git.andrew.burgess@embecosm.com>

Adds information about the precise git version from which gdb was
built.  The new version string will look like this:

  GNU gdb (GDB) 10.0.50.20200307-git (137acc6fbd6-72fbdf834da-2-dirty)

The first half (up to the '-git' string) is as before, and taken from
the version.in file within the gdb source tree, with the date text
taken from the bfd source tree.

The second part is new, and is built from the current git version.
This is broken down like this:

  137acc6fbd6-72fbdf834da-2-dirty
  |         | |         | | |   |
  '---A-----' '-----B---' C '-D-'

Where:
 A - This is the last git commit sha.  This represents the HEAD of the
     branch that was built.
 B - This is the merge base between the current branch and the
     upstream master branch.
 C - The number of commits from the merge base to the current sha.
     This gives an impression of how diverged the branch is.
 D - Is the current git tree fully committed? If not then it is dirty.

Parts B, C, and D are optional, though B and C will almost always
appear together (see below for details).  The following are all valid:

  137acc6fbd6-72fbdf834da-2-dirty

Current HEAD is 137acc6fbd6, which is 2 commits from the merge-base
72fbdf834da (which is in sourceware's master branch), however, the
repository that built this GDB was not fully committed, so 137acc6fbd6
will not accurately represent the source code that built this GDB.

  137acc6fbd6-72fbdf834da-2

Like the above, but the repository was fully committed, so 137acc6fbd6
does exactly match the source code that built this version of GDB.

  72fbdf834da-dirty

This version of GDB was built directly from sourceware's master
branch (commit 72fbdf834da), however the repository had local changes
at the time of build, so 72fbdf834da does not exactly match the source
code that built this version of GDB.

  72fbdf834da

Like the above, but the repository was clean at the time of build, so
72fbdf834da exactly matches that source code that built this version
of GDB.

  137acc6fbd6-unknown-dirty
  137acc6fbd6-unknown

These occur when the version script can't find the remote sourceware
repository, and so is unable to figure out a suitable merge-base, nor
can the script figure out if the current HEAD is in sourceware's
master branch.  In this case parts B and C are replaced with the
string 'unknown'.

I have tried to ensure that if the source code is not a git repository
then the git version token will not be added, so folks building from
tar files should get exactly what they had before.

The file gdbsupport/remote-repository contains the pattern used to
identify the remote repository, and the name of the upstream branch
from that repository which we care about.  For us this will be
sourceware and master, but by moving these strings into a separate
file anyone maintaining an out of tree GDB can easily update these to
point to their repository and branch, and get project specific version
strings.

gdbsupport/ChangeLog:

	* create-version.sh: Add git sha information.
	* remote-repository: New file.

gdbserver/ChangeLog:

	* Makefile.in (version-generated.cc): Add remote-repository file
	as a dependency.

gdb/ChangeLog:

	* Makefile.in (stamp-version): Add remote-repository file as a
	dependency.
---
 gdb/ChangeLog                |  5 +++
 gdb/Makefile.in              |  2 +-
 gdbserver/ChangeLog          |  5 +++
 gdbserver/Makefile.in        |  2 +-
 gdbsupport/ChangeLog         |  5 +++
 gdbsupport/create-version.sh | 90 ++++++++++++++++++++++++++++++++++++++++++++
 gdbsupport/remote-repository |  2 +
 7 files changed, 109 insertions(+), 2 deletions(-)
 create mode 100644 gdbsupport/remote-repository

diff --git a/gdb/Makefile.in b/gdb/Makefile.in
index 0c331af4bff..9b5ad1ea176 100644
--- a/gdb/Makefile.in
+++ b/gdb/Makefile.in
@@ -2068,7 +2068,7 @@ $(srcdir)/copying.c: @MAINTAINER_MODE_TRUE@ $(srcdir)/../COPYING3 $(srcdir)/copy
 version.c: stamp-version; @true
 # Note that the obvious names for the temp file are taken by
 # create-version.sh.
-stamp-version: Makefile version.in $(srcdir)/../bfd/version.h $(srcdir)/../gdbsupport/create-version.sh
+stamp-version: Makefile version.in $(srcdir)/../bfd/version.h $(srcdir)/../gdbsupport/create-version.sh $(srcdir)/../gdbsupport/remote-repository
 	$(ECHO_GEN) $(SHELL) $(srcdir)/../gdbsupport/create-version.sh $(srcdir) \
 	    $(host_alias) $(target_alias) version-t.t
 	@$(SHELL) $(srcdir)/../move-if-change version-t.t version.c
diff --git a/gdbserver/Makefile.in b/gdbserver/Makefile.in
index 8c35c169d62..0c67d64b02e 100644
--- a/gdbserver/Makefile.in
+++ b/gdbserver/Makefile.in
@@ -445,7 +445,7 @@ am--refresh:
 
 force:
 
-version-generated.cc: Makefile $(srcdir)/../gdb/version.in $(srcdir)/../bfd/version.h $(srcdir)/../gdbsupport/create-version.sh
+version-generated.cc: Makefile $(srcdir)/../gdb/version.in $(srcdir)/../bfd/version.h $(srcdir)/../gdbsupport/create-version.sh $(srcdir)/../gdbsupport/remote-repository
 	$(ECHO_GEN) $(SHELL) $(srcdir)/../gdbsupport/create-version.sh $(srcdir)/../gdb \
 		$(host_alias) $(target_alias) $@
 
diff --git a/gdbsupport/create-version.sh b/gdbsupport/create-version.sh
index 6135d219d94..68c6518615f 100755
--- a/gdbsupport/create-version.sh
+++ b/gdbsupport/create-version.sh
@@ -27,9 +27,99 @@ host_alias="$2"
 target_alias="$3"
 output="$4"
 
+GIT_TAG=""
+if (cd "$srcdir" && git rev-parse --show-toplevel >/dev/null 2>/dev/null); then
+
+    # The git version string looks something like this:
+    #
+    #     137acc6fbd6-72fbdf834da-2-dirty
+    #     |         | |         | | |   |
+    #     '---A-----' '-----B---' C '-D-'
+    #
+    # Where:
+    #   A - This is the last git commit sha.  This represents the HEAD of the
+    #       branch that was built.
+    #   B - This is the merge base between the current branch and the
+    #       upstream master branch.
+    #   C - The number of commits from the merge base to the current sha.
+    #       This gives an impression of how diverged the branch is.
+    #   D - Is the current git tree fully committed? If not then it is dirty.
+    #
+    # First figure out part A, the short sha for the current head:
+    short_head_sha=$(cd "$srcdir" && git rev-parse --short HEAD)
+
+    # Now figure out part D, the dirty tag.  This might be left as the
+    # empty string if the repository has no local changes.
+    dirty_mark=""
+    (cd "$srcdir" && git update-index -q --refresh)
+    test -z "$(cd "$srcdir" && git diff-index --name-only HEAD --)" ||
+	dirty_mark="-dirty"
+
+    # To calculate parts B and C we need to calculate the merge-base
+    # between the current branch and a specific remote branch.  The
+    # local file 'remote-repository' contains the remote repository
+    # url, and the branch name we are comparing against.  Here we
+    # extract that information.
+    remote_repo_pattern=$(grep ^pattern: \
+			       "$srcdir/../gdbsupport/remote-repository" \
+			      | cut -d: -f2-)
+    remote_repo_branch=$(grep ^branch: \
+			      "$srcdir/../gdbsupport/remote-repository" \
+			     | cut -d: -f2-)
+
+    # Use the remote url pattern from the remote-repository file to
+    # find the local name for the remote git repository.
+    remote_name=$( (cd "$srcdir" && git remote -v) \
+	| grep "${remote_repo_pattern}" | grep \(fetch\) \
+	| awk -F '\t' '{print $1}')
+    branch_info=""
+    if [ -n "${remote_name}" ]; then
+	# We found the local name for the remote repository, we can
+	# now go ahead and figure out parts B and C of the version
+	# string.
+	remote_branch="${remote_name}/${remote_repo_branch}"
+	# Check to see if the remote branch contains the current HEAD.
+	# If it does then the user is building directly from (their
+	# checkout of) the upstream branch.
+	if ! (cd "$srcdir"  && git merge-base \
+				   --is-ancestor "${short_head_sha}" \
+				   "${remote_branch}"); then
+	    # The current head sha is not on the remote tracking
+	    # branch.  We need to figure out the merge base, and the
+	    # distance from that merge base.
+	    merge_base_sha=$(cd "$srcdir" && git merge-base "${short_head_sha}" \
+					       "${remote_branch}")
+	    short_merge_base_sha=$(cd "$srcdir" \
+				       && git rev-parse \
+					      --short "${merge_base_sha}")
+
+	    # Count the commits between the merge base and current head.
+	    commit_count=$(cd "$srcdir" \
+			       && git rev-list --count "${merge_base_sha}"..HEAD)
+
+	    # Now format the parts B and C of the git version string.
+	    branch_info="-${short_merge_base_sha}-${commit_count}"
+	else
+	    # The user is building from a commit on the upstream
+	    # branch.  There's no need to include parts B and C of the
+	    # git version string.
+	    branch_info=""
+	fi
+    else
+	# We couldn't find the local name for the remote repository.
+	# Maybe this user has cloned from some other remote, or has
+	# deleted their remotes.
+	branch_info="-unknown"
+    fi
+    GIT_TAG="${short_head_sha}${branch_info}${dirty_mark}"
+fi
+
 rm -f version.c-tmp "$output" version.tmp
 date=$(sed -n -e 's/^.* BFD_VERSION_DATE \(.*\)$/\1/p' "$srcdir/../bfd/version.h")
 sed -e "s/DATE/$date/" < "$srcdir/version.in" > version.tmp
+if [ -n "$GIT_TAG" ]; then
+    echo " ($GIT_TAG)" >> version.tmp
+fi
 {
     echo '#include "gdbsupport/version.h"'
     echo 'const char version[] = "'"$(sed q version.tmp)"'";'
diff --git a/gdbsupport/remote-repository b/gdbsupport/remote-repository
new file mode 100644
index 00000000000..c05f3163e81
--- /dev/null
+++ b/gdbsupport/remote-repository
@@ -0,0 +1,2 @@
+pattern:sourceware.org/git/binutils-gdb.git
+branch:master
-- 
2.14.5



  parent reply	other threads:[~2020-03-27 12:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 11:48 [RFC] " Andrew Burgess
2020-03-26 14:55 ` Simon Marchi
2020-03-27 11:45   ` Andrew Burgess
2020-03-27 12:27   ` [PATCH 0/2] Adding git sha information to the " Andrew Burgess
2020-03-27 12:27   ` [PATCH 1/2] gdbsupport: Resolve shellcheck issues in create-version.sh script Andrew Burgess
2020-03-27 13:11     ` Simon Marchi
2020-03-27 13:57       ` Andrew Burgess
2020-03-27 12:27   ` Andrew Burgess [this message]
2020-03-27 13:56     ` [PATCH 2/2] Add git sha information to the gdb version string Simon Marchi
2020-03-27 15:28       ` Andrew Burgess
2020-03-27 15:42         ` Andreas Schwab
2020-03-27 16:18           ` Andrew Burgess
2020-03-27 15:48         ` Simon Marchi
2020-04-10  0:01     ` Joel Brobecker
2020-04-10  0:10       ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16599d81be47851f9ce53d7da037d9a1cdeba490.1585311874.git.andrew.burgess@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox