From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Simon Marchi <simark@simark.ca>
Cc: gdb-patches@sourceware.org, Joel Brobecker <brobecker@adacore.com>
Subject: Re: [PATCH 2/2] Add git sha information to the gdb version string
Date: Fri, 27 Mar 2020 15:28:34 +0000 [thread overview]
Message-ID: <20200327152834.GC587@embecosm.com> (raw)
In-Reply-To: <0b4bb502-4632-207c-cae6-94eeecb85f32@simark.ca>
* Simon Marchi <simark@simark.ca> [2020-03-27 09:56:35 -0400]:
> On 2020-03-27 8:27 a.m., Andrew Burgess wrote:
> > +
> > + # 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}')
>
> I just tried it locally, this is what I get:
>
> GNU gdb (GDB) 10.0.50.20200327-git (c13ff238f921--0)
>
> I identifier the problem to the fact that I have two remotes that match the given
> URL:
>
> $ git remote -v | grep 'sourceware.org/git/binutils-gdb.git'
> origin git://sourceware.org/git/binutils-gdb.git (fetch)
> origin git://sourceware.org/git/binutils-gdb.git (push)
> upstream ssh://sourceware.org/git/binutils-gdb.git (fetch)
> upstream ssh://sourceware.org/git/binutils-gdb.git (push)
OK. I hadn't considered that. But challenge accepted :)
The new version should handle multiple remotes and identify the most
up to date and use that one.
If try the version below and do 'git remote rename origin zzzzz', then
we should still find and use the zzzzz remote. I've done a bit of
basic testing but more exposure would be great.
Thanks,
Andrew
---
commit f5f1136f1549720f38d904016ded68e0b70bc99b
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date: Mon Mar 9 10:17:46 2020 +0000
Add git sha information to the gdb version string
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.
diff --git a/gdb/Makefile.in b/gdb/Makefile.in
index bc3ef695bbd..92a88f6d7e7 100644
--- a/gdb/Makefile.in
+++ b/gdb/Makefile.in
@@ -2071,7 +2071,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/ChangeLog b/gdbserver/ChangeLog
index 37e38611d5d..b52d6bccf95 100644
--- a/gdbserver/ChangeLog
+++ b/gdbserver/ChangeLog
@@ -1,3 +1,8 @@
+2020-03-27 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ * Makefile.in (version-generated.cc): Add remote-repository file
+ as a dependency.
+
2020-03-20 Simon Marchi <simon.marchi@efficios.com>
* config.in: Re-generate.
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/ChangeLog b/gdbsupport/ChangeLog
index 1d27971f5cc..1323894b407 100644
--- a/gdbsupport/ChangeLog
+++ b/gdbsupport/ChangeLog
@@ -1,3 +1,8 @@
+2020-03-27 Andrew Burgess <andrew.burgess@embecosm.com>
+
+ * create-version.sh: Add git sha information.
+ * remote-repository: New file.
+
2020-03-27 Andrew Burgess <andrew.burgess@embecosm.com>
* create-version.sh: Resolve issues highlighted by shellcheck.
diff --git a/gdbsupport/create-version.sh b/gdbsupport/create-version.sh
index 6135d219d94..52c8dc959d5 100755
--- a/gdbsupport/create-version.sh
+++ b/gdbsupport/create-version.sh
@@ -27,9 +27,182 @@ host_alias="$2"
target_alias="$3"
output="$4"
+# Takes two parameters extracted from the remote-repository file. The first
+# is the pattern for the remote repository, and the second is the name of
+# the remote branch to use.
+find_remote_name ()
+{
+ remote_repo_pattern=$1
+ remote_repo_branch=$2
+
+ # Use the remote url pattern from the remote-repository file to
+ # find the local name for the remote git repository. It might be
+ # that the user has multiple remotes all pointing at the same
+ # remote repository.
+ remote_names=$( (cd "$srcdir" && git remote -v) \
+ | grep "${remote_repo_pattern}" | grep \(fetch\) \
+ | awk -F '\t' '{print $1}')
+
+ # How many remotes did we find?
+ remote_count=$(echo "$remote_names" | wc -l)
+
+ # If we only found 0 or 1 remotes then we know what to do.
+ if [ "$remote_count" = 0 ]; then
+ echo ""
+ return
+ elif [ "$remote_count" = 1 ]; then
+ echo "$remote_names"
+ return
+ fi
+
+ # This user has multiple remotes all pointing at the upstream
+ # repository. We want to find the most up to date remote, and return
+ # its name. We don't worry about efficiency here, we assume that there
+ # will only be a couple of remote names pointing at the same remote url.
+ while IFS= read -r remote1; do
+ is_best=yes
+ branch1="$remote1/$remote_repo_branch"
+
+ # Check that this remote can give us a head sha. No point trying to
+ # use a remote that's just broken.
+ if ! (cd "$srcdir" && git rev-parse --short "$branch1" \
+ >/dev/null 2>/dev/null ); then
+ continue
+ fi
+
+ # Compare REMOTE1 agaist every other remote.
+ while IFS= read -r remote2; do
+ if [ "$remote1" != "$remote2" ]; then
+ branch2="$remote2/$remote_repo_branch"
+
+ # Again, check that REMOTE2 isn't just broken.
+ if ! (cd "$srcdir" && git rev-parse --short "$branch2" \
+ >/dev/null 2>/dev/null ); then
+ continue
+ fi
+
+ # If REMOTE2 is not an ancestor of REMOTE1 then REMOTE2 must
+ # have more recent commits than REMOTE1, so REMOTE1 is not
+ # the best choice. Two remotes pointing at the same commit
+ # are both ancestors of each other.
+ if ! (cd "$srcdir" && git merge-base \
+ --is-ancestor "$branch2" \
+ "$branch1"); then
+ is_best=no
+ fi
+ fi
+ done <<EOF
+$remote_names
+EOF
+
+ # If REMOTE1 still looks like the best choice then all other remotes
+ # are its ancestors. Worst case all other remotes point to the same
+ # commit as REMOTE1, best case, REMOTE1 has the newest commit.
+ if [ "$is_best" = "yes" ]; then
+ echo "${remote1}"
+ return
+ fi
+ done <<EOF
+$remote_names
+EOF
+
+ # None of the remotes appeared to be the "best". This is weird, but
+ # lets just take the first remote and assume that will give us something
+ # we can work with.
+ echo "$remote_names" | head -n1
+}
+
+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=$( find_remote_name "${remote_repo_pattern}" "${remote_repo_branch}" )
+ 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
next prev parent reply other threads:[~2020-03-27 15:28 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 ` [PATCH 2/2] Add git sha information to the gdb version string Andrew Burgess
2020-03-27 13:56 ` Simon Marchi
2020-03-27 15:28 ` Andrew Burgess [this message]
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=20200327152834.GC587@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