why replace breakpoint three times whhen next command

why replace breakpoint three times whhen next command

[周春明(日月)]

Dear GDB experts,

I encounter a wired problem, when I run next command, replace-breakpoint process is executed three times.
As I understand, the next command steps should be:
1. GDB replaces trap instruction with original instruction, and set a temporary breakpoint after this instruction.
2. resume this thread until the temporary breakpoint is hit.
3. when this temporary breakpoint is hit, place trap instruction at original place so that other thread can hit.

My problem is above progress is looped three times by GDB.

Any of you can give some insight on it? what problem could be ?  On which condition, GDB would continue to replace breakpoint?

Thanks in advance,
-David
------------------------------------------------------------------
发件人：Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
发送时间：2021年9月24日(星期五) 06:07
收件人：Simon Marchi <simon.marchi@polymtl.ca>; gdb-patches <gdb-patches@sourceware.org>
主　题：Re: [PATCH][gdb/testsuite] Dump /proc/cpuinfo into gdb.log

On 9/23/21 4:32 PM, Simon Marchi wrote:
> 
> 
> On 2021-09-21 4:01 a.m., Tom de Vries via Gdb-patches wrote:
>> Hi,
>>
>> When interpreting the testsuite results, it's often relevant what kind of
>> machine the testsuite ran on.  On a local machine one can just do
>> /proc/cpuinfo, but in case of running tests using a remote system
>> that distributes test runs to other remote systems that are not directly
>> accessible, that's not possible.
>>
>> Fix this by dumping /proc/cpuinfo into the gdb.log.
>>
>> We could do this at the start of each test run, by putting it into unix.exp
>> or some such.  However, this might be too verbose, so we choose to put it into
>> its own test-case, such that it get triggered in a full testrun, but not when
>> running one or a subset of tests.
>>
>> We put the test-case into the gdb.testsuite directory, which is currently the
>> only place in the testsuite where we do not test gdb.   Though perhaps this
>> should be put into a new gdb.info directory, since the test-case doesn't
>> actually test the testsuite.
> 
> I think in the gdb.testsuite directory is fine.
> 

Ack (still leaving the comment in the log message though).

> I like the idea.  I even think it would be useful to dump more things
> about the system, like:
> 
>  - "--version" output of compilers used for testing
>  - "lsb_release -a" output (if lsb_release is available)
>  - "uname -a" output (if uname is available)

I've added the latter two (and renamed the test-case to
dump-system-info.exp).

I'm not sure about compiler version, ISTM we already have that
information in the log (though you may have to grep for it).

> Can you think of more?
> 

Atm not, no.  I guess we can add if and when we think of something else.
 At least this gives us a place to add it to.

I'll commit tomorrow unless there are further comments.

Thanks,
- Tom

> Simon
> 

回复：why replace breakpoint three times whhen next command

[周春明(日月)]

I found there was message "
process_event_stop_test: stepping inside range [0x7fffee000008-0x7fffee000028]  ",
does that mean if a stepping inside a range, it will continue to do replace-breakpoint?
By the way, how GDB calculate the stepping range?

Thanks,
-Riyue


------------------------------------------------------------------
发件人：周春明(日月) <riyue.zcm@alibaba-inc.com>
发送时间：2021年9月24日(星期五) 17:56
收件人：Gdb-patches <gdb-patches-bounces+riyue.zcm=alibaba-inc.com@sourceware.org>; Simon Marchi <simon.marchi@polymtl.ca>; gdb-patches <gdb-patches@sourceware.org>
主　题：why replace breakpoint three times whhen next command

Dear GDB experts,

I encounter a wired problem, when I run next command, replace-breakpoint process is executed three times.
As I understand, the next command steps should be:
1. GDB replaces trap instruction with original instruction, and set a temporary breakpoint after this instruction.
2. resume this thread until the temporary breakpoint is hit.
3. when this temporary breakpoint is hit, place trap instruction at original place so that other thread can hit.

My problem is above progress is looped three times by GDB.

Any of you can give some insight on it? what problem could be ?  On which condition, GDB would continue to replace breakpoint?

Thanks in advance,
-David
------------------------------------------------------------------
发件人：Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
发送时间：2021年9月24日(星期五) 06:07
收件人：Simon Marchi <simon.marchi@polymtl.ca>; gdb-patches <gdb-patches@sourceware.org>
主　题：Re: [PATCH][gdb/testsuite] Dump /proc/cpuinfo into gdb.log

On 9/23/21 4:32 PM, Simon Marchi wrote:
> 
> 
> On 2021-09-21 4:01 a.m., Tom de Vries via Gdb-patches wrote:
>> Hi,
>>
>> When interpreting the testsuite results, it's often relevant what kind of
>> machine the testsuite ran on.  On a local machine one can just do
>> /proc/cpuinfo, but in case of running tests using a remote system
>> that distributes test runs to other remote systems that are not directly
>> accessible, that's not possible.
>>
>> Fix this by dumping /proc/cpuinfo into the gdb.log.
>>
>> We could do this at the start of each test run, by putting it into unix.exp
>> or some such.  However, this might be too verbose, so we choose to put it into
>> its own test-case, such that it get triggered in a full testrun, but not when
>> running one or a subset of tests.
>>
>> We put the test-case into the gdb.testsuite directory, which is currently the
>> only place in the testsuite where we do not test gdb.   Though perhaps this
>> should be put into a new gdb.info directory, since the test-case doesn't
>> actually test the testsuite.
> 
> I think in the gdb.testsuite directory is fine.
> 

Ack (still leaving the comment in the log message though).

> I like the idea.  I even think it would be useful to dump more things
> about the system, like:
> 
>  - "--version" output of compilers used for testing
>  - "lsb_release -a" output (if lsb_release is available)
>  - "uname -a" output (if uname is available)

I've added the latter two (and renamed the test-case to
dump-system-info.exp).

I'm not sure about compiler version, ISTM we already have that
information in the log (though you may have to grep for it).

> Can you think of more?
> 

Atm not, no.  I guess we can add if and when we think of something else.
 At least this gives us a place to add it to.

I'll commit tomorrow unless there are further comments.

Thanks,
- Tom

> Simon
> 

Re: 回复：why replace breakpoint three times whhen next command

[Simon Marchi]

On 2021-09-26 05:30, 周春明(日月) wrote:
> I found there was message "
> 
> process_event_stop_test: stepping inside range [0x7fffee000008-0x7fffee000028]  
> 
> ",
> does that mean if a stepping inside a range, it will continue to do replace-breakpoint?
> By the way, how GDB calculate the stepping range?

I'm not 100% I understand your question, but what you described here:


>     Dear GDB experts,
> 
>     I encounter a wired problem, when I run next command, replace-breakpoint process is executed three times.
>     As I understand, the next command steps should be:
>     1. GDB replaces trap instruction with original instruction, and set a temporary breakpoint after this instruction.
>     2. resume this thread until the temporary breakpoint is hit.
>     3. when this temporary breakpoint is hit, place trap instruction at original place so that other thread can hit.

... is what would happen when stepping over a breakpoint on an
architecture without hardware single-step and without using displaced
stepping.

If you type "next" or "step" while stopped at a breakpoint, GDB will
step over instruction where the breakpoint is, but will also keep
stepping instructions as long as the instructions belong to the source
code line where the "next" or "step" started.  So you would see multiple
times GDB inserting a step-over breakpoint and resuming execution.

Simon