port-amd64/50221: kgdb: i386 OK but amd64 panic

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

>Number:         50221
>Category:       port-amd64
>Synopsis:       kgdb: i386 OK but amd64 panic
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-amd64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 09 12:40:00 +0000 2015
>Originator:     Patrick Welche
>Release:        NetBSD 7.99.21
>Organization:
>Environment:
NetBSD-7.99.21/amd64, source of 9 Sep 2015
gdb 7.9.1
>Description:
In PR port-amd64/50091 I relate in what way amd64 panics when trying kgdb
with a remote and target both being amd64.
In that PR Vicente Chaves hints that the issue is because the gdb
commands are being interpreted as for i386.
So, I just tested my setup just by swapping an amd64 target for an
i386 target. Success:

Sending packet: $g#67...Ack
Packet received: 0000000000000000010000002000000094ae0dc194ae0dc1cd000000f8660d0124e310c002020000080000001000000010000000100000003000000010000000
Sending packet: $qL1200000000000000000#50...Ack
Packet received: 
Sending packet: $mc010e324,1#bc...Ack
Packet received: 5d
...
(gdb) show architecture
The target architecture is set automatically (currently i386)
(gdb) bt
#0  0xc010e324 in breakpoint ()
Sending packet: $mc10daea8,4#54...Ack
Packet received: 01000000
#1  0xc0110c25 in kgdb_connect (verbose=verbose@entry=1)
    at /usr/src/local/netbsd/src/sys/arch/i386/i386/kgdb_machdep.c:235
...


Trying the following .gdbinit in the amd64 case:

set remote interrupt-sequence BREAK
set serial baud 115200
set remotetimeout 3
set debug remote 1
set remotelogfile protocol.txt
show architecture
set architecture i386:x86-64
show architecture
target remote /dev/tty00

The target architecture is set automatically (currently i386)
The target architecture is assumed to be i386:x86-64
The target architecture is assumed to be i386:x86-64
Sending packet: $qSupported:multiprocess+;xmlRegisters=i386;qRelocInsn+#b5...Ack
...
Sending packet: $g#67...Ack
Packet received: 0f0000000000000020000000000000000000000000000000010000000000000000801b81ffffffff0000000000000000c0be1781ffffffffc0be1781ffffffff00801b81ffffffffd00700000000000000801b81ffffffffb0c5f880ffffffff0a1800000000000010ed0f010000000000000000000000001850aed700000000b54a1180ffffffff860200000000000008000000000000001000000000000000
Sending packet: $qL1200000000000000000#50...Ack
Packet received: 
Sending packet: $m811b8000,1#8e...Ack
Timed out.
Timed out.

with or without the set architecture line...

I note that in Vincente's trace in PR 50091, he sees a "p" command,
whereas I see a "m" command. "p" reads the value of a register
whereas "m" reads a memory location.
>How-To-Repeat:
Try to debug a amd64 target.
>Fix:
Rather than a kernel locking bug, this is looking more like a gdb
architecture detection bug...