Re: qemu-system-sparc64: entering the debugger

On 12/04/16 13:51, Mark Cave-Ayland wrote:

> On 12/04/16 10:06, Mark Cave-Ayland wrote:
> 
>>> So it looks like something has already gone wrong simply trying to dump
>>> the process map. Fortunately the number of QEMU translation blocks
>>> between the output of the "ps/m" header and the "KDB reentering" is
>>> quite small so I've uploaded it to
>>> https://www.ilande.co.uk/tmp/qemu/freebsd-tb.txt.
>>>
>>> Can anyone have a quick look at the link above and give me an idea as to
>>> roughly what the code is doing here?
> 
> It seems that if you boot directly into ddb and use ps/m then you end up
> with a NULL pointer dereference:
> 
> FreeBSD/sparc64 bootstrap loader, Revision 1.0
> (mca@freebsd, Thu Sep 24 00:27:19 BST 2015)
> bootpath="/pci@1fe,0/pci-ata@5/ide1@8200/cdrom@0:a"
> Loading /boot/defaults/loader.conf
> /boot/kernel/kernel data=0xd893c0+0x20ffd8 syms=[0x8+0xdc578+0x8+0xcb349]
> \
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel] in 9 seconds...
> 
> Type '?' for a list of commands, 'help' for more detailed help.
> OK boot -d
> Booting...
> jumping to kernel entry at 0xc00b0000.
> GDB: no debug ports present
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> KDB: enter: Boot flags requested debugger
> [ thread pid 0 tid 0 ]
> Stopped at      0xc0630b00
> db> ps/m
>   pid  ppid  pgrp   uid   state   wmesg         wchan        cmd
>     0     0     0     0KDB: reentering
> KDB: stack backtrace:
>  (null)() at 0xc063105c
> (null)() at 0xc09e193c
> (null)() at 0xc00b1078
> (null)() at 0xc011bb1c
> 
> The NULL pointer reference occurs here:
> 
> 0x00000000c0122008:  ldx  [ %l2 + 0x3d8 ], %g1     ! %g1 = 0
> 0x00000000c012200c:  ldx  [ %g1 + 0x18 ], %g1      !
> 0x00000000c0122010:  brz,pn   %g1, 0xc0122050
> 0x00000000c0122014:  nop
> 
> AFAICT the corresponding part of db_ps.c is this:
> 
> if (p->p_session != NULL && SESS_LEADER(p))
>     strlcat(state, "s", sizeof(state));
> 
> Here p->p_session expands to p->p_pgrp->pg_session which gives us the
> exception because p->p_pgrp is set to NULL. So I guess this is a bug,
> but not the bug I'm looking for...
> 
> (Note: I know this is an oldish checkout, so maybe someone else has
> already found and fixed this)

I've just tried this with the latest SPARC64 current ISO
(FreeBSD-11.0-CURRENT-sparc64-20160408-r297692) and the bug is still
there, plus it occurs on my amd64 image too so this isn't just a SPARC64
issue.

Also trying to use continue to exit from ddb doesn't seem to work under
qemu-system-sparc64 either:

$ ./qemu-system-sparc64 -cdrom
FreeBSD-11.0-CURRENT-sparc64-20160408-r297692-disc1.iso -boot d -m 512
-nographic
OpenBIOS for Sparc64
Configuration device id QEMU version 1 machine id 0
kernel cmdline
CPUs: 1 x SUNW,UltraSPARC-IIi
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.1 built on Feb 26 2016 10:39
  Type 'help' for detailed information
Trying cdrom:f...
Not a bootable ELF image
Loading a.out image...
Loaded 7680 bytes
entry point is 0x4000

Jumping to entry point 0000000000004000 for type 0000000000000005...
switching to new context: entry point 0x4000 stack 0x00000000ffe84a09

>> FreeBSD/sparc64 boot block
   Boot path:   /pci@1fe,0/pci-ata@5/ide1@8200/cdrom@0:f
   Boot loader: /boot/loader
Consoles: Open Firmware console

FreeBSD/sparc64 bootstrap loader, Revision 1.0
([email protected], Fri Apr  8 06:07:07 UTC 2016)
bootpath="/pci@1fe,0/pci-ata@5/ide1@8200/cdrom@0:a"
Loading /boot/defaults/loader.conf
/boot/kernel/kernel data=0xd1cc40+0x2137d8 syms=[0x8+0xdf260+0x8+0xcddb9]
\
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel] in 9 seconds...

Type '?' for a list of commands, 'help' for more detailed help.
OK boot -d
Booting...
jumping to kernel entry at 0xc00b0000.
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
KDB: enter: Boot flags requested debugger
[ thread pid 0 tid 0 ]
Stopped at      0xc062b5e0
db> continue
db>

Can anyone confirm whether or not this works on real hardware or whether
it is another QEMU bug?


ATB,

Mark.

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "[email protected]"