Re: [PATCH 04/12] Delete reinsert breakpoints from forked child

[Pedro Alves <palves@redhat.com>]

On 06/13/2016 05:53 PM, Yao Qi wrote:
> 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, 

Yes, we do.

> and garbage is printed, 

Yes, it does.  Easily confirmed:

(gdb) disassemble $pc,+10
Dump of assembler code from 0x7ffff78c55bb to 0x7ffff78c55c5:
=> 0x00007ffff78c55bb <__libc_fork+187>:        cmp    $0xfffffffffffff000,%rax
   0x00007ffff78c55c1 <__libc_fork+193>:        ja     0x7ffff78c5716 <__libc_fork+534>
End of assembler dump.
(gdb) disassemble $pc-1,+10
Dump of assembler code from 0x7ffff78c55ba to 0x7ffff78c55c4:
   0x00007ffff78c55ba <__libc_fork+186>:        add    $0xf0003d48,%eax
   0x00007ffff78c55bf <__libc_fork+191>:        (bad)  
   0x00007ffff78c55c0 <__libc_fork+192>:        decl   (%rdi)
   0x00007ffff78c55c2 <__libc_fork+194>:        xchg   %ecx,0x1(%rdi)
End of assembler dump.
(gdb) 

> it is a bug, and we should fix in disassembler.

The problem is that with variable length instructions,
there's no way to tell where an instruction starts by going
backwards...  All you can do is disassemble forward from some
known instruction boundary.  "disassemble" without a closed range
uses the the function's address to know where to start.

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

Now that the negative repeat count for 'x' patch [1] is in,
you can just do "x/-i $pc".  Maybe "disassemble" could learn
to find boundaries similarly.  

But that x/-i trick only works if the code has line info available,
which you won't for _exit, unless you have debug info for glibc
installed.  Maybe better is to just do "disassemble", with no args,
which disassembles the whole function.

Or do it like step-over-syscall.exp does.

[1] https://sourceware.org/ml/gdb-patches/2016-06/msg00021.html

>> 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?  

As I mention in the quoted sentence below, the last one
would single-step the instruction with no breakpoint
installed.  The second one would have a breakpoint at PC,
which forces a step-over operation.  With displaced step
off, that'd be an in-line step over.  Thus the second one stops
all threads (and thus requires restarting them), while the
third one doesn't.

> I think
> they've already covered by gdb.base/step-over-syscall.exp.

In that case, shouldn't we be extending that test instead?

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

Thanks,
Pedro Alves