Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ATF tests hanging

On 28.12.2017 13:47, Martin Husemann wrote:
> On Wed, Dec 27, 2017 at 08:33:48PM +0100, Kamil Rytarowski wrote:
>> This is not a x86 bug.
>> It's an idiom in x86 to:
>>  - write software breakpoint
>>  - execute instruction (& move EIP/RIP)
>>  - detect trap
>>  - report to debugger
>>  - rewind IP
>>  - write original code
>>  - [offer prompt to a user; interaction; etc]
>>  - option to resume from the retrieved instruction
>> There is a different behavior with hardware assisted (debug registers)
>> instruction trap. As we trap before the execution of an instruction and
>> there is no need to rewind the IP.
>> In general these specific nits are to be handled in a debugger.
> Yes, but not in your test program.

I've designed it with lack of PT_WRITE_I/PIOD_WRITE_I usage in mind, to
simplify the test case. It requires manual handling of RIP for some ports.

>> Of course, we can try to streamline the behavior in all ports to behave
>> exactly the same way. The SPARC behavior is certainly mild from a
>> debugger point of view.
> I don't understand why you consider the x86 one more natural, you trap
> on the breakpoint and that is where %pc is, you replace the breakpoint
> instruction with the original and PT_CONTINUE, no need to play with
> the IP.

I don't want to argue that one of them is more natural than the other.
As I have noted, on x86 there are both characteristics available
(software and hardware breakpoint are different in terms of EIP/RIP).

> Also exactly this behaviour is needed for the %npc != (%pc + 4) case you
> cited in the other mail (which is not a bug in our implementation, but
> a restriction of the PT_CONTINUE interface where only a single address
> to resume from may be specified).
> Martin

I will adopt this test for other CPUs.

Attachment: signature.asc
Description: OpenPGP digital signature

Home | Main Index | Thread Index | Old Index