public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: Matti Puputti <matti.puputti@intel.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH v6 1/1] gdb, infcmd: Support jump command in multi-inferior case.
Date: Wed, 16 Aug 2023 09:58:48 +0100	[thread overview]
Message-ID: <87bkf7cqif.fsf@redhat.com> (raw)
In-Reply-To: <20230726122915.212016-1-matti.puputti@intel.com>

Matti Puputti <matti.puputti@intel.com> writes:

> From: "Puputti, Matti" <matti.puputti@intel.com>
>
> Fixes the issue where jump failed if multiple inferiors run the same
> source.

Thanks for the latest update.

I took another look through, this looks great, so I have pushed this to
master.

I did add a new comment to the 'do_test' proc in the test script, and
extended the description of the fix in the commit message.

Thanks,
Andrew



>
> See the below example
>
>     $ gdb -q ./simple
>     Reading symbols from ./simple...
>     (gdb) break 2
>     Breakpoint 1 at 0x114e: file simple.c, line 2.
>     (gdb) run
>     Starting program: /temp/simple
>
>     Breakpoint 1, main () at simple.c:2
>     2         int a = 42;
>     (gdb) add-inferior
>     [New inferior 2]
>     Added inferior 2 on connection 1 (native)
>     (gdb) inferior 2
>     [Switching to inferior 2 [<null>] (<noexec>)]
>     (gdb) info inferiors
>       Num  Description       Connection           Executable
>       1    process 6250      1 (native)           /temp/simple
>     * 2    <null>            1 (native)
>     (gdb) file ./simple
>     Reading symbols from ./simple...
>     (gdb) run
>     Starting program: /temp/simple
>
>     Thread 2.1 "simple" hit Breakpoint 1, main () at simple.c:2
>     2         int a = 42;
>     (gdb) info inferiors
>       Num  Description       Connection           Executable
>       1    process 6250      1 (native)           /temp/simple
>     * 2    process 6705      1 (native)           /temp/simple
>     (gdb) jump 3
>     Unreasonable jump request
>     (gdb)
>
> In this example, jump fails because the debugger finds two different
> locations, one for each inferior.
> Solution is to limit the search to the current program space.
> ---
>  gdb/infcmd.c                    |   2 +-
>  gdb/linespec.c                  |   3 +-
>  gdb/testsuite/gdb.base/jump.exp | 180 +++++++++++++++++---------------
>  3 files changed, 98 insertions(+), 87 deletions(-)
>
> diff --git a/gdb/infcmd.c b/gdb/infcmd.c
> index 15702f84894..96c5feafb1a 100644
> --- a/gdb/infcmd.c
> +++ b/gdb/infcmd.c
> @@ -1068,7 +1068,7 @@ jump_command (const char *arg, int from_tty)
>      error_no_arg (_("starting address"));
>  
>    std::vector<symtab_and_line> sals
> -    = decode_line_with_last_displayed (arg, DECODE_LINE_FUNFIRSTLINE);
> +    = decode_line_with_current_source (arg, DECODE_LINE_FUNFIRSTLINE);
>    if (sals.size () != 1)
>      {
>        /* If multiple sal-objects were found, try dropping those that aren't
> diff --git a/gdb/linespec.c b/gdb/linespec.c
> index 7d969f37fbf..afa9eb4d3ac 100644
> --- a/gdb/linespec.c
> +++ b/gdb/linespec.c
> @@ -3220,7 +3220,8 @@ decode_line_with_current_source (const char *string, int flags)
>    location_spec_up locspec = string_to_location_spec (&string,
>  						      current_language);
>    std::vector<symtab_and_line> sals
> -    = decode_line_1 (locspec.get (), flags, NULL, cursal.symtab, cursal.line);
> +    = decode_line_1 (locspec.get (), flags, cursal.pspace, cursal.symtab,
> +		    cursal.line);
>  
>    if (*string)
>      error (_("Junk at end of line specification: %s"), string);
> diff --git a/gdb/testsuite/gdb.base/jump.exp b/gdb/testsuite/gdb.base/jump.exp
> index 032c4a6279d..77765db15ef 100644
> --- a/gdb/testsuite/gdb.base/jump.exp
> +++ b/gdb/testsuite/gdb.base/jump.exp
> @@ -18,99 +18,109 @@ clear_xfail "*-*-*"
>  
>  standard_testfile .c
>  
> -# Build the test case
> -if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug nowarnings}] != "" } {
> -     untested "failed to compile"
> -     return -1
> -    }
> +if {[prepare_for_testing "failed to prepare" $testfile $srcfile]} {
> +    return -1
> +}
>  
>  
> -# Start with a fresh gdb
> +proc do_tests {} {
> +    global decimal srcfile
> +
> +    # Set a breakpoint on the statement that we're about to jump to.
> +    # The statement doesn't contain a function call.
> +    set non_call_line [gdb_get_line_number "bp-on-non-call"]
> +    gdb_breakpoint "$non_call_line"
> +    set bp_on_non_call \
> +	[get_integer_valueof "\$bpnum" "INVALID" "bp_on_non_call"]
> +
> +    # Can we jump to the statement?  Do we stop there?
> +    gdb_test "jump $non_call_line" \
> +	"Breakpoint ${bp_on_non_call}(\.${decimal})?, .*${srcfile}:$non_call_line.*" \
> +	"jump to non-call"
> +
> +    # Set a breakpoint on the statement that we're about to jump to.
> +    # The statement does contain a function call.
> +    set call_line [gdb_get_line_number "bp-on-call"]
> +    gdb_breakpoint "$call_line"
> +    set bp_on_call [get_integer_valueof "\$bpnum" "INVALID" "bp_on_call"]
> +
> +    # Can we jump to the statement?  Do we stop there?
> +    gdb_test "jump $call_line" \
> +	"Breakpoint ${bp_on_call}(\.${decimal})?, .*${srcfile}:$call_line.*" \
> +	"jump to call"
> +
> +    # If we disable the breakpoint at the function call, and then
> +    # if we jump to that statement, do we not stop there, but at
> +    # the following breakpoint?
> +    gdb_test_no_output "disable $bp_on_call" "disable breakpoint on call"
> +
> +    gdb_test "jump $call_line" \
> +	"Breakpoint ${bp_on_non_call}(\.${decimal})?, .*${srcfile}:$non_call_line.*" \
> +	"jump to call with disabled breakpoint"
> +
> +    # Disable the breakpoint at the non-function call, so it won't hit
> +    # if do_test is called again.
> +    gdb_test_no_output "disable ${bp_on_non_call}" "disable bp_on_non_call"
> +
> +    # Verify that GDB responds gracefully to the "jump" command without
> +    # an argument.
> +    gdb_test "jump" "Argument required .starting address.*" \
> +	"jump without argument disallowed"
> +
> +    # Verify that GDB responds gracefully to the "jump" command with
> +    # trailing junk.
> +    gdb_test "jump $call_line 100" \
> +	"malformed linespec error: unexpected number, \"100\"" \
> +	"jump with trailing argument junk"
> +
> +    # Verify that GDB responds gracefully to a request to jump out of
> +    # the current function.  (Note that this will very likely cause the
> +    # inferior to die.  Be prepared to rerun the inferior, if further
> +    # testing is desired.)
> +    # Try it both ways: confirming and not confirming the jump.
> +    set out_line [gdb_get_line_number "out-of-func"]
> +    gdb_test "jump $out_line" \
> +	"Not confirmed.*" \
> +	"aborted jump out of current function" \
> +	"Line $out_line is not in `main'.  Jump anyway.*y or n. $" \
> +	"n"
> +
> +    gdb_test "jump $out_line" \
> +	"Continuing at.*" \
> +	"jump out of current function" \
> +	"Line $out_line is not in `main'.  Jump anyway.*y or n. $" \
> +	"y"
> +}
>  
> -clean_restart ${binfile}
>  
> -if {![runto_main]} {
> -  return -1
> +set num_inferiors 1
> +if {![use_gdb_stub]} {
> +    set num_inferiors 2
>  }
>  
> -# Set a breakpoint on the statement that we're about to jump to.
> -# The statement doesn't contain a function call.
> -#
> -set bp_on_non_call 0
> -set non_call_line [gdb_get_line_number "bp-on-non-call"]
> -gdb_test_multiple "break $non_call_line" "break before jump to non-call" {
> -    -re "\[Bb\]reakpoint (${decimal}) at ${hex}: file .*${srcfile}, line $non_call_line.*$gdb_prompt $" {
> -	set bp_on_non_call $expect_out(1,string)
> -	pass "break before jump to non-call"
> +# Run to main, add inferiors if needed.
> +if {![runto_main]} {
> +    return -1
> +}
> +for {set inf 2} {$inf <= $num_inferiors} {incr inf} {
> +    # Start a new inferior, and run it with the same executable.
> +    gdb_test "add-inferior -exec ${binfile}" \
> +	"Added inferior ${inf}.*" \
> +	"add inferior ${inf} with -exec "
> +    gdb_test "inferior ${inf}" \
> +	"Switching to inferior ${inf} .*" \
> +	"switch to inferior ${inf}"
> +    if {![runto_main]} {
> +	return -1
>      }
>  }
>  
> -# Can we jump to the statement?  Do we stop there?
> -#
> -gdb_test "jump $non_call_line" "Breakpoint ${decimal}, .*${srcfile}:$non_call_line.*" \
> -    "jump to non-call"
> -
> -# Set a breakpoint on the statement that we're about to jump to.
> -# The statement does contain a function call.
> -#
> -set bp_on_call 0
> -set call_line [gdb_get_line_number "bp-on-call"]
> -gdb_test_multiple "break $call_line" "break before jump to call" {
> -    -re "\[Bb\]reakpoint (${decimal}) at ${hex}: file .*${srcfile}, line $call_line.*$gdb_prompt $" {
> -	set bp_on_call $expect_out(1,string)
> -	pass "break before jump to call"
> +# Run tests on all inferiors.
> +for {set inf 1} {$inf <= $num_inferiors} {incr inf} {
> +    with_test_prefix "inferior $inf" {
> +	# Switch to the target inferior.
> +	gdb_test "inferior $inf" ".*Switching to inferior $inf .*"
> +	# Run the tests.
> +	do_tests
>      }
>  }
> -
> -# Can we jump to the statement?  Do we stop there?
> -#
> -gdb_test "jump $call_line" \
> -    "Breakpoint ${decimal}, .*${srcfile}:$call_line.*" \
> -    "jump to call"
> -
> -# If we disable the breakpoint at the function call, and then
> -# if we jump to that statement, do we not stop there, but at
> -# the following breakpoint?
> -#
> -gdb_test_no_output "disable $bp_on_call" "disable breakpoint on call"
> -
> -gdb_test "jump $call_line" "Breakpoint ${decimal}, .*${srcfile}:$non_call_line.*" \
> -    "jump to call with disabled breakpoint"
> -
> -# Verify that GDB responds gracefully to the "jump" command without
> -# an argument.
> -#
> -gdb_test "jump" "Argument required .starting address.*" \
> -    "jump without argument disallowed"
> -
> -
> -# Verify that GDB responds gracefully to the "jump" command with
> -# trailing junk.
> -#
> -gdb_test "jump $call_line 100" \
> -    "malformed linespec error: unexpected number, \"100\"" \
> -    "jump with trailing argument junk"
> -
> -
> -# Verify that GDB responds gracefully to a request to jump out of
> -# the current function.  (Note that this will very likely cause the
> -# inferior to die.  Be prepared to rerun the inferior, if further
> -# testing is desired.)
> -#
> -# Try it both ways: confirming and not confirming the jump.
> -#
> -
> -set out_line [gdb_get_line_number "out-of-func"]
> -gdb_test "jump $out_line" \
> -    "Not confirmed.*" \
> -    "aborted jump out of current function" \
> -    "Line $out_line is not in `main'.  Jump anyway.*y or n. $" \
> -    "n"
> -
> -gdb_test "jump $out_line" \
> -    "Continuing at.*" \
> -    "jump out of current function" \
> -    "Line $out_line is not in `main'.  Jump anyway.*y or n. $" \
> -    "y"
> -
> -gdb_exit
> -- 
> 2.25.1
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928


  reply	other threads:[~2023-08-16  8:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-26 12:29 Matti Puputti
2023-08-16  8:58 ` Andrew Burgess [this message]
2023-08-16 10:55   ` Puputti, Matti

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=87bkf7cqif.fsf@redhat.com \
    --to=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=matti.puputti@intel.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).