public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
From: gdb-buildbot@sergiodj.net
To: gdb-testers@sourceware.org
Subject: [binutils-gdb] gdb: Ensure that !(a < a) is true in sort_cmp on obj_section objects
Date: Wed, 23 Oct 2019 20:46:00 -0000	[thread overview]
Message-ID: <45f47c3a25d7574d21b9f451efce38c06256f591@gdb-build> (raw)

*** TEST RESULTS FOR COMMIT 45f47c3a25d7574d21b9f451efce38c06256f591 ***

commit 45f47c3a25d7574d21b9f451efce38c06256f591
Author:     Andrew Burgess <andrew.burgess@embecosm.com>
AuthorDate: Mon Oct 21 16:39:51 2019 +0100
Commit:     Andrew Burgess <andrew.burgess@embecosm.com>
CommitDate: Mon Oct 21 21:10:02 2019 +0100

    gdb: Ensure that !(a < a) is true in sort_cmp on obj_section objects
    
    After the switch to use std::sort, if GDB is compiled with the
    -D_GLIBCXX_DEBUG=1 flag then we see an error when using sort_cmp (in
    objfiles.c) to sort obj_section objects.
    
    The problem is that std::sort checks that the condition !(a < a)
    holds, and currently this is not true.  GDB's sort_cmp is really
    designed to sort lists in which no obj_section repeats, however, there
    is some code in place to try and ensure we get a stable sort order if
    there is a bug in GDB, unfortunately this code fails the above check.
    
    By reordering some of the checks inside sort_cmp, it is pretty easy to
    ensure that the !(a < a) condition holds.
    
    I've not bothered to make this condition check optimal, like I said
    this code is only in place to ensure that we get stable results if GDB
    goes wrong, so I've made the smallest change needed to get the correct
    behaviour.
    
    After this commit I see no regressions when running GDB compiled with
    -D_GLIBCXX_DEBUG=1.
    
    gdb/ChangeLog:
    
            * objfiles.c (sort_cmp): Ensure that !(a < a) holds true.
    
    Change-Id: I4b1e3e1640865104c0896cbb6c3fdbbc04d9645b

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 44980f25d1..41ee329fc1 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,7 @@
+2019-10-21  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	* objfiles.c (sort_cmp): Ensure that !(a < a) holds true.
+
 2019-10-21  Tom Tromey  <tom@tromey.com>
 
 	* tui/tui-winsource.h (tui_exec_info_content): Remove typedef.
diff --git a/gdb/objfiles.c b/gdb/objfiles.c
index fd1cbf764d..b5bc09f41e 100644
--- a/gdb/objfiles.c
+++ b/gdb/objfiles.c
@@ -1044,19 +1044,23 @@ sort_cmp (const struct obj_section *sect1, const obj_section *sect2)
 	 doesn't happen at all).  If you discover that significant time is
 	 spent in the loops below, do 'set complaints 100' and examine the
 	 resulting complaints.  */
-
       if (objfile1 == objfile2)
 	{
-	  /* Both sections came from the same objfile.  We are really confused.
-	     Sort on sequence order of sections within the objfile.  */
+	  /* Both sections came from the same objfile.  We are really
+	     confused.  Sort on sequence order of sections within the
+	     objfile.  The order of checks is important here, if we find a
+	     match on SECT2 first then either SECT2 is before SECT1, or,
+	     SECT2 == SECT1, in both cases we should return false.  The
+	     second case shouldn't occur during normal use, but std::sort
+	     does check that '!(a < a)' when compiled in debug mode.  */
 
 	  const struct obj_section *osect;
 
 	  ALL_OBJFILE_OSECTIONS (objfile1, osect)
-	    if (osect == sect1)
-	      return true;
-	    else if (osect == sect2)
+	    if (osect == sect2)
 	      return false;
+	    else if (osect == sect1)
+	      return true;
 
 	  /* We should have found one of the sections before getting here.  */
 	  gdb_assert_not_reached ("section not found");


             reply	other threads:[~2019-10-23 20:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23 20:46 gdb-buildbot [this message]
2019-10-23 20:46 ` Failures on Ubuntu-Aarch64-native-extended-gdbserver-m64, branch master gdb-buildbot
2019-10-23 21:00 ` Failures on Ubuntu-Aarch64-native-gdbserver-m64, " gdb-buildbot
2019-11-08 10:39 ` Failures on Fedora-i686, " gdb-buildbot
2019-11-08 11:29 ` Failures on Fedora-x86_64-m32, " gdb-buildbot
2019-11-08 11:36 ` Failures on Fedora-x86_64-m64, " gdb-buildbot
2019-11-08 12:22 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " gdb-buildbot
2019-11-08 12:31 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " gdb-buildbot
2019-11-08 13:04 ` Failures on Fedora-x86_64-native-gdbserver-m32, " gdb-buildbot
2019-11-08 13:19 ` Failures on Fedora-x86_64-native-gdbserver-m64, " gdb-buildbot

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=45f47c3a25d7574d21b9f451efce38c06256f591@gdb-build \
    --to=gdb-buildbot@sergiodj.net \
    --cc=gdb-testers@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).