public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: [PATCH][gdb/testsuite] Avoid breakpoint in GLIBC in gdb.threads/execl.exp
Date: Thu, 12 Mar 2020 00:45:44 +0100	[thread overview]
Message-ID: <20200311234542.GA340@delia> (raw)

Hi,

When running the gdb.threads/execl.exp test-case, we run into this FAIL:
...
(gdb) continue^M
Continuing.^M
^M
Thread 1 "execl" hit Breakpoint 2, __GI_execl (path=0x6024a0 \
  "build/gdb/testsuite/outputs/gdb.threads/execl/execl1", \
  arg=<optimized out>) at execl.c:51^M
51        if (execl (new_image, new_image, NULL) == -1) \
  /* set breakpoint here */^M
(gdb) FAIL: gdb.threads/execl.exp: continue across exec
...
The fail is due to the continue command hitting a breakpoint in __GI_execl
rather than main.

This problem originates from where we execute the "b 51" command, and get two
breakpoint locations:
...
(gdb) run ^M
Starting program: build/gdb/testsuite/outputs/gdb.threads/execl/execl ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
^M
Breakpoint 1, main (argc=1, argv=0x7fffffffd3f8) at gdb.threads/execl.c:44^M
44        pthread_create (&thread1, NULL, thread_function, NULL);^M
(gdb) b 51^M
Breakpoint 2 at 0x400787: gdb.threads/execl.c:51. (2 locations)^M
(gdb) PASS: gdb.threads/execl.exp: set breakpoint at execl
...

Adding a "info breakpoints" command, we can see the locations:
...
(gdb) info breakpoints^M
Num     Type           Disp Enb Address            What^M
1       breakpoint     keep y   0x00000000004006ee in main at \
  gdb.threads/execl.c:44^M
        breakpoint already hit 1 time^M
2       breakpoint     keep y   <MULTIPLE>         ^M
2.1                         y   0x0000000000400787 in main at \
  gdb.threads/execl.c:51^M
2.2                         y   0x00007ffff758d925 in __GI_execl at \
  execl.c:51^M
(gdb) PASS: gdb.threads/execl.exp: info breakpoints
...

The fact that the __GI_execl breakpoint location is there, is a bug, filed as
PR25656.  Without debug info for GLIBC though, the bug is not triggered.

Fix the FAIL by working around the bug, and deleting the breakpoint after
hitting the first breakpoint location.

Tested on x86_64-linux.

OK for trunk?

Thanks,
- Tom

[gdb/testsuite] Avoid breakpoint in GLIBC in gdb.threads/execl.exp

gdb/testsuite/ChangeLog:

2020-03-12  Tom de Vries  <tdevries@suse.de>

	* gdb.threads/execl.exp: Delete breakpoint after hitting it.

---
 gdb/testsuite/gdb.threads/execl.exp | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/gdb/testsuite/gdb.threads/execl.exp b/gdb/testsuite/gdb.threads/execl.exp
index 5f28fed142..1649081f83 100644
--- a/gdb/testsuite/gdb.threads/execl.exp
+++ b/gdb/testsuite/gdb.threads/execl.exp
@@ -42,6 +42,13 @@ gdb_test "continue" ".*breakpoint here.*" "continue to exec"
 
 gdb_test "info threads" "1 *Thread.*2 *Thread.*3 *Thread.*" "info threads before exec"
 
+# Work around PR25656, where the breakpoint above sets 2 breakpoint locations:
+# - one on gdb.threads/execl.c:$linenumber, and
+# - one in GLIBC's execl.c:$linenumber, in __GI_execl
+# Delete the breakpoint to make sure we hit main upon continue, rather than
+# __GI_execl.
+gdb_test_no_output "delete 2"
+
 # When continuing from this point we'll hit the breakpoint in main()
 # again, this time in the exec'd process.
 gdb_test "continue" ".*Breakpoint 1, main.*" \

             reply	other threads:[~2020-03-11 23:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 23:45 Tom de Vries [this message]
2020-03-12 13:34 ` Tom Tromey

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=20200311234542.GA340@delia \
    --to=tdevries@suse.de \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.com \
    /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).