[Qemu-devel] target-ppc: gdbstub breakpoints get stuck in an infinite loop on next/continue

[Qemu-devel] target-ppc: gdbstub breakpoints get stuck in an infinite loop on next/continue

[Mark Cave-Ayland]

Hi all,

I've just noticed the above regression in git master whilst trying to
debug something in openbios-ppc via QEMU's gdbstub. Reproduction here is
fairly easy using a debug build of OpenBIOS which I've uploaded to
https://www.ilande.co.uk/tmp/qemu/openbios-qemu.elf.nostrip for people
to test against.

./qemu-system-ppc -bios openbios-qemu.elf.nostrip -s -S

The infinite loop can be seen by adding a breakpoint to the OpenBIOS
boot() function using gdb as below:

$ powerpc-linux-gdb obj-ppc/openbios-qemu.elf.nostrip
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu
--target=powerpc-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from obj-ppc/openbios-qemu.elf.nostrip...done.
(gdb) target remote :1234
Remote debugging using :1234

vector.0x100 () at
/home/build/src/openbios/openbios.git/openbios/arch/ppc/qemu/start.S:284
284             b       _entry

(gdb) b boot

Breakpoint 1 at 0xfff0bc00: file
/home/build/src/openbios/openbios.git/openbios/arch/ppc/qemu/main.c,
line 75.

(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0xfff0bbfc in boot () at
/home/build/src/openbios/openbios.git/openbios/arch/ppc/qemu/main.c:74
74      {
(gdb) n

At this point the gdb session hangs whilst the GTK window title is
constantly switching between paused/unpaused.

A session with git bisect shows the bug was introduced with the
following commit:

bd6fefe71cec5a0c7d2be4ac96307f25db56abf9 is the first bad commit
commit bd6fefe71cec5a0c7d2be4ac96307f25db56abf9
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Wed Jul 27 16:56:32 2016 +1000

    ppc: Make tlb_fill() use new exception helper

    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

:040000 040000 3494b2d68eef71c8f7c7d4e57c5ff715146028b2
00849bf5889d8ee5b5ce633122b7aedf4a734372 M      linux-user
:040000 040000 32b1a8078a44c44e6bfd2184061b6da553cfc821
58afefec7a9fc5380fb408758a11dbe749010b97 M      target-ppc


ATB,

Mark.

Re: [Qemu-devel] target-ppc: gdbstub breakpoints get stuck in an infinite loop on next/continue

[Benjamin Herrenschmidt]

On Fri, 2016-10-21 at 15:18 +0100, Mark Cave-Ayland wrote:
> 
> bd6fefe71cec5a0c7d2be4ac96307f25db56abf9 is the first bad commit
> commit bd6fefe71cec5a0c7d2be4ac96307f25db56abf9
> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date:   Wed Jul 27 16:56:32 2016 +1000
> 
>     ppc: Make tlb_fill() use new exception helper
> 
>     Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>     Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> 
> :040000 040000 3494b2d68eef71c8f7c7d4e57c5ff715146028b2
> 00849bf5889d8ee5b5ce633122b7aedf4a734372 M      linux-user
> :040000 040000 32b1a8078a44c44e6bfd2184061b6da553cfc821
> 58afefec7a9fc5380fb408758a11dbe749010b97 M      target-ppc

Hrm, that patch does a lot more that the subject (and lack of cset
comment) implies. I wonder if it got some rebase damage here.

In the meantime, look at 24a2d2ac2cfbb699cab216aaf118c8503f22817c
" ppc: Fix single step with gdb stub" in my wip branch, see if that
helps.

Re: [Qemu-devel] target-ppc: gdbstub breakpoints get stuck in an infinite loop on next/continue

[Mark Cave-Ayland]

On 21/10/16 23:02, Benjamin Herrenschmidt wrote:

> On Fri, 2016-10-21 at 15:18 +0100, Mark Cave-Ayland wrote:
>>  
>> bd6fefe71cec5a0c7d2be4ac96307f25db56abf9 is the first bad commit
>> commit bd6fefe71cec5a0c7d2be4ac96307f25db56abf9
>> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Date:   Wed Jul 27 16:56:32 2016 +1000
>>
>>     ppc: Make tlb_fill() use new exception helper
>>
>>     Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>     Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>
>> :040000 040000 3494b2d68eef71c8f7c7d4e57c5ff715146028b2
>> 00849bf5889d8ee5b5ce633122b7aedf4a734372 M      linux-user
>> :040000 040000 32b1a8078a44c44e6bfd2184061b6da553cfc821
>> 58afefec7a9fc5380fb408758a11dbe749010b97 M      target-ppc
> 
> Hrm, that patch does a lot more that the subject (and lack of cset
> comment) implies. I wonder if it got some rebase damage here.

Indeed, it looks like extra changes were squashed into that single patch
between these two pull requests:

6th September:
https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg00887.html

7th September:
https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg01465.html

> In the meantime, look at 24a2d2ac2cfbb699cab216aaf118c8503f22817c
> " ppc: Fix single step with gdb stub" in my wip branch, see if that
> helps.

Yes it does - I've cherry-picked this onto master and I can confirm that
it fixes the gdbstub issues I was seeing here.

David, any chance we can we get this queued into your ppc-for-2.8 branch?


ATB,

Mark.

Re: [Qemu-devel] target-ppc: gdbstub breakpoints get stuck in an infinite loop on next/continue

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]

On Sat, Oct 22, 2016 at 09:22:45AM +0100, Mark Cave-Ayland wrote:
> On 21/10/16 23:02, Benjamin Herrenschmidt wrote:
> 
> > On Fri, 2016-10-21 at 15:18 +0100, Mark Cave-Ayland wrote:
> >>  
> >> bd6fefe71cec5a0c7d2be4ac96307f25db56abf9 is the first bad commit
> >> commit bd6fefe71cec5a0c7d2be4ac96307f25db56abf9
> >> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >> Date:   Wed Jul 27 16:56:32 2016 +1000
> >>
> >>     ppc: Make tlb_fill() use new exception helper
> >>
> >>     Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >>     Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >>
> >> :040000 040000 3494b2d68eef71c8f7c7d4e57c5ff715146028b2
> >> 00849bf5889d8ee5b5ce633122b7aedf4a734372 M      linux-user
> >> :040000 040000 32b1a8078a44c44e6bfd2184061b6da553cfc821
> >> 58afefec7a9fc5380fb408758a11dbe749010b97 M      target-ppc
> > 
> > Hrm, that patch does a lot more that the subject (and lack of cset
> > comment) implies. I wonder if it got some rebase damage here.
> 
> Indeed, it looks like extra changes were squashed into that single patch
> between these two pull requests:
> 
> 6th September:
> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg00887.html
> 
> 7th September:
> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg01465.html

Crap.  Yeah, looks like a screwed up a rebase.

> > In the meantime, look at 24a2d2ac2cfbb699cab216aaf118c8503f22817c
> > " ppc: Fix single step with gdb stub" in my wip branch, see if that
> > helps.
> 
> Yes it does - I've cherry-picked this onto master and I can confirm that
> it fixes the gdbstub issues I was seeing here.
> 
> David, any chance we can we get this queued into your ppc-for-2.8 branch?

Done.

Ben, does it look like the other extraneous changes in bd6fefe are at
least correct, apart from being in the wrong patch?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] target-ppc: gdbstub breakpoints get stuck in an infinite loop on next/continue

[Benjamin Herrenschmidt]

On Mon, 2016-10-24 at 12:00 +1100, David Gibson wrote:
> Ben, does it look like the other extraneous changes in bd6fefe are at
> least correct, apart from being in the wrong patch?

It looks like part of my big rewrite of the exception stuff, so I'd
assume it's mostly correct minus a few bugs I fixed separately such
as the one we are just talking about :-)

Cheers,
Ben.