Re: port-amd64/50091

[Vicente Chaves de Melo <vchaves%ymail.com@localhost>]

The following reply was made to PR port-amd64/50091; it has been noted by GNATS.

From: Vicente Chaves de Melo <vchaves%ymail.com@localhost>
To: gnats-bugs%NetBSD.org@localhost, port-amd64-maintainer%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-amd64/50091
Date: Tue, 28 Jul 2015 23:34:30 -0300

 Hi Patrick,
 looking more carefully at the address that the packet m is trying to read,
 appears to be the contents of the eip register case gdb remote was 
 interpreting the g packet as i386 port.
 
 What is the port you are using on the server remote gdb?
 
 What is the output you get when you run the command show architecture in 
 gdb?
 
 Best regards
 Vicente
 
 
 On 28/07/2015 09:55, Patrick Welche wrote:
 > The following reply was made to PR port-amd64/50091; it has been noted by GNATS.
 >
 > From: Patrick Welche <prlw1%cam.ac.uk@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: port-amd64/50091
 > Date: Tue, 28 Jul 2015 13:50:26 +0100
 >
 >   Sadly kgdb is still broken for me even after this change. My gdb
 >   protocol trace is slightly different in that I have a "m" (read
 >   memory) rather than "p" (read register) after the "g" (read
 >   registers). This is today's current, so odd to see a difference:
 >   
 >   ...
 >   Sending packet: $qC#b4...Ack
 >   Packet received:
 >   Sending packet: $qAttached#8f...Ack
 >   Packet received:
 >   Packet qAttached (query-attached) is NOT supported
 >   Sending packet: $g#67...Ack
 >   Packet received: 0f000000000000002000000000000000000000000000000001000000000000000060f280ffffffff0000000000000000c09eee80ffffffffc09eee80ffffffff0060f280ffffffffd0070000000000000060f280ffffffff7300000000000000000000000000000000000000000000000000000000000000000000000000000035c31e80ffffffff860200000000000008000000000000001000000000000000
 >   Sending packet: $m80f26000,1#90...Ack
 >   Timed out.
 >   
 >   The time out is because the target panics with a
 >   
 >   panic: lockdebug_lookup: uninitialized lock (lock=0xffffffff80d01448, from=fff807bc16a)
 >   
 >   after having just done a sys/arch/amd64/amd64/kgdb_machdep.c,
 >   kgdb_acc(va=0x80f26000,len=1)
 >   
 >   i.e., the panic happens in
 >   
 >   pte = kvtopte(va)      (as VM_MN_KERNEL_ADDRESS=0)
 >   
 >   (as per http://mail-index.netbsd.org/tech-kern/2015/07/09/msg019142.html)
 >