Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <qiyaoltc@gmail.com>
To: Pedro Alves <palves@redhat.com>
Cc: Yao Qi <qiyaoltc@gmail.com>,  gdb-patches@sourceware.org
Subject: Re: [PATCH 04/12] Delete reinsert breakpoints from forked child
Date: Mon, 13 Jun 2016 16:53:00 -0000	[thread overview]
Message-ID: <86twgxt4hg.fsf@gmail.com> (raw)
In-Reply-To: <eca5a71d-867b-1f84-e66a-bca6e1e0254e@redhat.com> (Pedro Alves's	message of "Mon, 13 Jun 2016 16:02:25 +0100")

Pedro Alves <palves@redhat.com> writes:

> Hmm, "\$pc - 20" doesn't look right for e.g., x86 with variable
> length instructions.  I think that can well start disassembling
> in the middle of an instruction, and produce garbage.
>

I thought 20 is big enough to include the previous instruction in.
The max instruction length of x86 is 16.  If we disassemble in the
middle of an instruction, and garbage is printed, it is a bug, and we
should fix in disassembler.

I can't find another way to show the previous instruction.

>> +	-re " ($hex)\[^\r\n\]+\r\n=> .*$gdb_prompt $" {
>> +	    set syscall_insn_addr $expect_out(1,string)
>> +	    pass $test
>> +	}
>> +    }
>> +
>> +    if { $syscall_insn_addr == "" } {
>> +	fail $test
>> +	return
>> +    }
>> +
>> +    delete_breakpoints
>> +
>> +    gdb_test "break marker"
>> +
>> +    gdb_test "continue" "Continuing\\..*Breakpoint $decimal, .*" \
>> +	"continue to marker (1)"
>
> No " ($foo)".
>

I'll fix it.

>> +    set test "set breakpoint condition-evaluation target"
>> +    gdb_test_multiple $test $test {
>> + -re "warning: Target does not support breakpoint condition
>> evaluation.\r\nUsing host evaluation mode instead.\r\n$gdb_prompt $"
>> {
>> +	    # Target doesn't support breakpoint condition
>> +	    # evaluation on its side.
>> +	}
>> +	-re "^$test\r\n$gdb_prompt $" {
>> +	}
>> +    }
>
> No pass call?
>

I'll fix it.

>> +    # Create a breakpoint which evaluates false.
>> +    gdb_test "break \*$syscall_insn_addr if main == 0" \
>> +	"Breakpoint \[0-9\]* at .*"
>
> This ends up with "$syscall_insn_addr" in the test message.
>
>
> I'm thinking that it might be good for these tests to also have
> a displaced-stepping on/off test axis.  Or better still:
>
>  out-of-line-step-over-bp / in-line-step-over-bp / plain-single-step
>

What is difference between the second one and third one?  I think
they've already covered by gdb.base/step-over-syscall.exp.

> with the single-step variant doing a single-step over the
> syscall instruction, with no breakpoint at PC at all.

-- 
Yao (齐尧)


  reply	other threads:[~2016-06-13 16:53 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-02  9:31 [PATCH 00/12 V2] Use reinsert breakpoint for vCont;s Yao Qi
2016-06-02  9:31 ` [PATCH 05/12] Handle reinsert breakpoints for vforked child Yao Qi
2016-06-13 15:07   ` Pedro Alves
2016-06-02  9:31 ` [PATCH 10/12] Switch current_thread to lwp's thread in install_software_single_step_breakpoints Yao Qi
2016-06-13 15:26   ` Pedro Alves
2016-06-02  9:31 ` [PATCH 12/12] Support vCont s and S actions with software single step Yao Qi
2016-06-13 15:56   ` Pedro Alves
2016-06-02  9:31 ` [PATCH 04/12] Delete reinsert breakpoints from forked child Yao Qi
2016-06-13 15:02   ` Pedro Alves
2016-06-13 16:53     ` Yao Qi [this message]
2016-06-13 17:29       ` Pedro Alves
2016-06-14 11:17         ` Yao Qi
2016-06-14 11:40           ` Pedro Alves
2016-06-17  9:53             ` Yao Qi
2016-06-02  9:31 ` [PATCH 02/12] More assert checks on reinsert breakpoint Yao Qi
2016-06-13 14:25   ` Pedro Alves
2016-06-02  9:31 ` [PATCH 11/12] Use reinsert_breakpoint for vCont;s Yao Qi
2016-06-13 15:55   ` Pedro Alves
2016-06-14 13:14     ` Yao Qi
2016-06-14 15:48       ` Pedro Alves
2016-06-15 16:41         ` Yao Qi
2016-06-17 15:10           ` Pedro Alves
2016-06-20 18:09             ` Antoine Tremblay
2016-06-02  9:31 ` [PATCH 01/12] Switch to current thread in finish_step_over Yao Qi
2016-06-13 14:25   ` Pedro Alves
2016-06-02  9:31 ` [PATCH 08/12] Refactor clone_all_breakpoints Yao Qi
2016-06-13 15:14   ` Pedro Alves
2016-06-02  9:31 ` [PATCH 09/12] Make reinsert_breakpoint thread specific Yao Qi
     [not found]   ` <71a5322e-41e3-9e23-df73-e14b14c1d656@redhat.com>
2016-06-14 12:52     ` Yao Qi
2016-06-14 12:57       ` Pedro Alves
2016-06-02  9:31 ` [PATCH 07/12] Create sub classes of 'struct breakpoint' Yao Qi
2016-06-13 15:09   ` Pedro Alves
2016-06-02  9:31 ` [PATCH 03/12] Step over exit with reinsert breakpoints Yao Qi
2016-06-13 14:37   ` Pedro Alves
2016-06-13 14:52     ` Yao Qi
2016-06-13 15:01       ` Pedro Alves
2016-06-17  9:50         ` Yao Qi
2016-06-02  9:31 ` [PATCH 06/12] Pass breakpoint type in set_breakpoint_at Yao Qi
2016-06-13 15:07   ` Pedro Alves

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=86twgxt4hg.fsf@gmail.com \
    --to=qiyaoltc@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.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