gdb 8.3.1 truncated register in remote g packet

gdb 8.3.1 truncated register in remote g packet

[Reinoud Koornstra]

Hello Everyone,

I downloaded an compiled gdb 8.3.1 with --target=arm-linux-gnueabihf on my
x86_64 pc.
Compiled and installed fine. I started the gdb with the vmlinux file and
tried to connect to the remote arm32 machine: target remote /dev/ttyUSB0
Then I get: Truncated register 19  in remote 'g' packet.
What is going wrong here? I saw earlier archives about similar issues, but
i thought those would have been patched. Any help would be appreciated.
Thanks,

Reinoud.

Re: gdb 8.3.1 truncated register in remote g packet

[Luis Machado]

Hi Reinoud,

On 10/31/19 3:58 PM, Reinoud Koornstra wrote:
> Hello Everyone,
> 
> I downloaded an compiled gdb 8.3.1 with --target=arm-linux-gnueabihf on my
> x86_64 pc.
> Compiled and installed fine. I started the gdb with the vmlinux file and
> tried to connect to the remote arm32 machine: target remote /dev/ttyUSB0
> Then I get: Truncated register 19  in remote 'g' packet.
> What is going wrong here? I saw earlier archives about similar issues, but
> i thought those would have been patched. Any help would be appreciated.
That error means your remote arm32 machine's debugging stub doesn't 
agree with GDB in terms of the register set. GDB is likely assuming 
register set A and the debugging stub is assuming register set B.

You can check what the debugging stub is sending via "set debug remote 
1". If it supports XML register descriptions, you'll see data flying by.

If it doesn't, then GDB is probably making a guess as to what the proper 
register set is.

In summary, i think we need more data in order to make an informer guess 
on what is going wrong here, but probably GDB and the debugging stub are 
not in sync in terms of registers.

> Thanks,
> 
> Reinoud.
> 

Re: gdb 8.3.1 truncated register in remote g packet

[Reinoud Koornstra]

On Fri, Nov 1, 2019 at 9:11 AM Luis Machado <luis.machado@linaro.org> wrote:

> Hi Reinoud,
>
> Hi Luis,
Thanks for your response.

>
> That error means your remote arm32 machine's debugging stub doesn't
> agree with GDB in terms of the register set. GDB is likely assuming
> register set A and the debugging stub is assuming register set B.
>
> You can check what the debugging stub is sending via "set debug remote
> 1". If it supports XML register descriptions, you'll see data flying by.
>
> If it doesn't, then GDB is probably making a guess as to what the proper
> register set is.
>
> In summary, i think we need more data in order to make an informer guess
> on what is going wrong here, but probably GDB and the debugging stub are
> not in sync in terms of registers.
>
 Here's more output with debug remote.
sudo gdb-for-arm/bin/arm-linux-gnueabihf-gdb ./vmlinux
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 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-pc-linux-gnu
--target=arm-linux-gnueabihf".
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 ./vmlinux...
(gdb) set serial baud 115200
(gdb) set debug remote 1
(gdb) target remote /dev/ttyUSB4
Remote debugging using /dev/ttyUSB4
Sending packet:
$qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
Packet received:
Packet qSupported (supported-packets) is NOT supported
Sending packet: $vMustReplyEmpty#3a...Ack
Packet received:
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $qTStatus#49...Ack
Packet received:
Packet qTStatus (trace-status) is NOT supported
Sending packet: $?#3f...Ack
Packet received: S05
Sending packet: $qfThreadInfo#bb...Ack
Packet received:
mfffffffe,fffffffd,01,02,03,05,06,07,08,09,0a,0b,0c,0d,0e,0f,10,11,12
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
m0147,014a,014c,0164,016f,0198,01a3,01a9,01dc,01ea,04b3,0502,0511,0512,0513,0514,0515
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
m0523,0524,0525,0535,0540,0548,0614,098d,0992,0993,09bf,09c2,09c8,09cd,09ce,09db,09e1
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
m09ea,09f7,09ff,0a36,0a3e,0a4b,0a51,0a57,0a58,0a5a,0a5b,0a5d,0a5e,0a5f,0aa4,0aa6,0aa8
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
m0af2,0af3,0af4,0afa,0afc,0b7d,0b9a,0b9b,0b9c,0c1d,0cb8,0b96,0be9,0beb,0bf7,0bfb,0bfc
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
m0bfd,0bfe,0bff,0c00,0c01,0c02,0c03,0c04,0c05,0c06,0c60,0c65,0c67,0c68,0c6d,0c6e,0c7c
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
m0c7d,0c7f,0ce5,0df6,0e2f,0e39,0e3b,0e3d,0e5d,0e3e,0e3f,0e41,0e8c,0e8e,0ea3,0eaf,0ebc
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
m0ebe,0ebf,0ec1,0ec2,0ec5,0ec7,0ec9,0ed0,0ed3,0ed4,0eca,0ecc,0ece,0ecf,0ed2,0edc,1061
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
m1105,13fb,144c,145a,14b6,14c8,14cd,14e0,14f4,150b,1510,1511,1512,1514,1699,169b,169d
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
m169e,169f,16a0,16a1,16a2,16cd,16cf,16d1,16d2,16d3,16d7,16dd,16de,16df,16e0,16e1,16e2
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
m16e3,16e4,16e6,1961,1c81,1c82,1c83,1c84,1c85,1c86,1c87,16f2,16f3,16f5,16f6,16fc,1758
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
m1759,175a,16f7,16f8,16fa,1704,1706,1719,1723,1724,1725,1734,1735,1741,1744,1747,1877
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
m187b,187d,1880,188f,1893,193b,1949,194a,194f,1952,1957,1a78,1c75,1c77,1c9d,1eb4,1eb6
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
m1eb8,1ebe,29ed,0149,096c,1334,184d,1df6,1f3f,2123,2165,2175,2183
Sending packet: $qsThreadInfo#c8...Ack
Packet received:
Sending packet: $qAttached#8f...Ack
Packet received:
Packet qAttached (query-attached) is NOT supported
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received: QC0aa8
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $g#67...Ack
Packet received:
0000000001000000b0829e80ac829e8054829880b4a698806700000013000060060000000000000000000000cc3e27bed03e27bec03e27be10200a80581f0a8000000000000000000000000000000000000000000000000000000000000000000000000000000000
Truncated register 19 in remote 'g' packet

>
>
Thanks, Reinoud.

Re: gdb 8.3.1 truncated register in remote g packet

[Luis Machado]

Hi,

On 11/1/19 3:24 PM, Reinoud Koornstra wrote:
> On Fri, Nov 1, 2019 at 9:11 AM Luis Machado <luis.machado@linaro.org 
> <mailto:luis.machado@linaro.org>> wrote:
> 
>     Hi Reinoud,
> 
> Hi Luis,
> Thanks for your response.
> 
> 
>     That error means your remote arm32 machine's debugging stub doesn't
>     agree with GDB in terms of the register set. GDB is likely assuming
>     register set A and the debugging stub is assuming register set B.
> 
>     You can check what the debugging stub is sending via "set debug remote
>     1". If it supports XML register descriptions, you'll see data flying by.
> 
>     If it doesn't, then GDB is probably making a guess as to what the
>     proper
>     register set is.
> 
>     In summary, i think we need more data in order to make an informer
>     guess
>     on what is going wrong here, but probably GDB and the debugging stub
>     are
>     not in sync in terms of registers.
> 
>   Here's more output with debug remote.
> sudo gdb-for-arm/bin/arm-linux-gnueabihf-gdb ./vmlinux
> GNU gdb (GDB) 8.3.1
> Copyright (C) 2019 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-pc-linux-gnu 
> --target=arm-linux-gnueabihf".
> 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 ./vmlinux...
> (gdb) set serial baud 115200
> (gdb) set debug remote 1
> (gdb) target remote /dev/ttyUSB4
> Remote debugging using /dev/ttyUSB4
> Sending packet: 
> $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
> Packet received:
> Packet qSupported (supported-packets) is NOT supported

This is not great.

If the debugging stub doesn't support qSupported, then it means GDB will 
need to guess what the stub's register set is, and that can be tricky.

Do you know what register set the debugging stub is using?

> Sending packet: $vMustReplyEmpty#3a...Ack
> Packet received:
> Sending packet: $Hg0#df...Ack
> Packet received: OK
> Sending packet: $qTStatus#49...Ack
> Packet received:
> Packet qTStatus (trace-status) is NOT supported
> Sending packet: $?#3f...Ack
> Packet received: S05
> Sending packet: $qfThreadInfo#bb...Ack
> Packet received: 
> mfffffffe,fffffffd,01,02,03,05,06,07,08,09,0a,0b,0c,0d,0e,0f,10,11,12
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: 
> m0147,014a,014c,0164,016f,0198,01a3,01a9,01dc,01ea,04b3,0502,0511,0512,0513,0514,0515
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: 
> m0523,0524,0525,0535,0540,0548,0614,098d,0992,0993,09bf,09c2,09c8,09cd,09ce,09db,09e1
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: 
> m09ea,09f7,09ff,0a36,0a3e,0a4b,0a51,0a57,0a58,0a5a,0a5b,0a5d,0a5e,0a5f,0aa4,0aa6,0aa8
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: 
> m0af2,0af3,0af4,0afa,0afc,0b7d,0b9a,0b9b,0b9c,0c1d,0cb8,0b96,0be9,0beb,0bf7,0bfb,0bfc
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: 
> m0bfd,0bfe,0bff,0c00,0c01,0c02,0c03,0c04,0c05,0c06,0c60,0c65,0c67,0c68,0c6d,0c6e,0c7c
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: 
> m0c7d,0c7f,0ce5,0df6,0e2f,0e39,0e3b,0e3d,0e5d,0e3e,0e3f,0e41,0e8c,0e8e,0ea3,0eaf,0ebc
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: 
> m0ebe,0ebf,0ec1,0ec2,0ec5,0ec7,0ec9,0ed0,0ed3,0ed4,0eca,0ecc,0ece,0ecf,0ed2,0edc,1061
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: 
> m1105,13fb,144c,145a,14b6,14c8,14cd,14e0,14f4,150b,1510,1511,1512,1514,1699,169b,169d
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: 
> m169e,169f,16a0,16a1,16a2,16cd,16cf,16d1,16d2,16d3,16d7,16dd,16de,16df,16e0,16e1,16e2
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: 
> m16e3,16e4,16e6,1961,1c81,1c82,1c83,1c84,1c85,1c86,1c87,16f2,16f3,16f5,16f6,16fc,1758
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: 
> m1759,175a,16f7,16f8,16fa,1704,1706,1719,1723,1724,1725,1734,1735,1741,1744,1747,1877
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: 
> m187b,187d,1880,188f,1893,193b,1949,194a,194f,1952,1957,1a78,1c75,1c77,1c9d,1eb4,1eb6
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received: 
> m1eb8,1ebe,29ed,0149,096c,1334,184d,1df6,1f3f,2123,2165,2175,2183
> Sending packet: $qsThreadInfo#c8...Ack
> Packet received:
> Sending packet: $qAttached#8f...Ack
> Packet received:
> Packet qAttached (query-attached) is NOT supported
> Sending packet: $Hc-1#09...Ack
> Packet received: OK
> Sending packet: $qC#b4...Ack
> Packet received: QC0aa8
> Sending packet: $qOffsets#4b...Ack
> Packet received:
> Sending packet: $g#67...Ack
> Packet received: 
> 0000000001000000b0829e80ac829e8054829880b4a698806700000013000060060000000000000000000000cc3e27bed03e27bec03e27be10200a80581f0a8000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Truncated register 19 in remote 'g' packet

Could you verify if there is real truncation in the data transmission? 
Do you have access to what the debugging stub is sending?

Re: gdb 8.3.1 truncated register in remote g packet

[Reinoud Koornstra]

[SNIP]

> This is not great.
>
> If the debugging stub doesn't support qSupported, then it means GDB will
> need to guess what the stub's register set is, and that can be tricky.
>
> Do you know what register set the debugging stub is using?
>
> I need to do some reading if I can see more about the register set and see
if I can see the whole transmission over serial to verify whether the
packet is truncated or not.
let me try to find out and get back to you.
Thanks, Reinoud.


> > Sending packet: $vMustReplyEmpty#3a...Ack
> > Packet received:
> > Sending packet: $Hg0#df...Ack
> > Packet received: OK
> > Sending packet: $qTStatus#49...Ack
> > Packet received:
> > Packet qTStatus (trace-status) is NOT supported
> > Sending packet: $?#3f...Ack
> > Packet received: S05
> > Sending packet: $qfThreadInfo#bb...Ack
> > Packet received:
> > mfffffffe,fffffffd,01,02,03,05,06,07,08,09,0a,0b,0c,0d,0e,0f,10,11,12
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> >
> m0147,014a,014c,0164,016f,0198,01a3,01a9,01dc,01ea,04b3,0502,0511,0512,0513,0514,0515
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> >
> m0523,0524,0525,0535,0540,0548,0614,098d,0992,0993,09bf,09c2,09c8,09cd,09ce,09db,09e1
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> >
> m09ea,09f7,09ff,0a36,0a3e,0a4b,0a51,0a57,0a58,0a5a,0a5b,0a5d,0a5e,0a5f,0aa4,0aa6,0aa8
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> >
> m0af2,0af3,0af4,0afa,0afc,0b7d,0b9a,0b9b,0b9c,0c1d,0cb8,0b96,0be9,0beb,0bf7,0bfb,0bfc
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> >
> m0bfd,0bfe,0bff,0c00,0c01,0c02,0c03,0c04,0c05,0c06,0c60,0c65,0c67,0c68,0c6d,0c6e,0c7c
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> >
> m0c7d,0c7f,0ce5,0df6,0e2f,0e39,0e3b,0e3d,0e5d,0e3e,0e3f,0e41,0e8c,0e8e,0ea3,0eaf,0ebc
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> >
> m0ebe,0ebf,0ec1,0ec2,0ec5,0ec7,0ec9,0ed0,0ed3,0ed4,0eca,0ecc,0ece,0ecf,0ed2,0edc,1061
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> >
> m1105,13fb,144c,145a,14b6,14c8,14cd,14e0,14f4,150b,1510,1511,1512,1514,1699,169b,169d
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> >
> m169e,169f,16a0,16a1,16a2,16cd,16cf,16d1,16d2,16d3,16d7,16dd,16de,16df,16e0,16e1,16e2
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> >
> m16e3,16e4,16e6,1961,1c81,1c82,1c83,1c84,1c85,1c86,1c87,16f2,16f3,16f5,16f6,16fc,1758
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> >
> m1759,175a,16f7,16f8,16fa,1704,1706,1719,1723,1724,1725,1734,1735,1741,1744,1747,1877
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> >
> m187b,187d,1880,188f,1893,193b,1949,194a,194f,1952,1957,1a78,1c75,1c77,1c9d,1eb4,1eb6
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> > m1eb8,1ebe,29ed,0149,096c,1334,184d,1df6,1f3f,2123,2165,2175,2183
> > Sending packet: $qsThreadInfo#c8...Ack
> > Packet received:
> > Sending packet: $qAttached#8f...Ack
> > Packet received:
> > Packet qAttached (query-attached) is NOT supported
> > Sending packet: $Hc-1#09...Ack
> > Packet received: OK
> > Sending packet: $qC#b4...Ack
> > Packet received: QC0aa8
> > Sending packet: $qOffsets#4b...Ack
> > Packet received:
> > Sending packet: $g#67...Ack
> > Packet received:
> >
> 0000000001000000b0829e80ac829e8054829880b4a698806700000013000060060000000000000000000000cc3e27bed03e27bec03e27be10200a80581f0a8000000000000000000000000000000000000000000000000000000000000000000000000000000000
> > Truncated register 19 in remote 'g' packet
>
> Could you verify if there is real truncation in the data transmission?
> Do you have access to what the debugging stub is sending?
>

Re: gdb 8.3.1 truncated register in remote g packet

[Reinoud Koornstra]

Hi Luis,
The remote platform is arm32. Weirdly enough, when I use a gdb 7.7 compiled
only for x86_64, it does seem to work a bit better, no clue exactly why.
Here's the output, why is this version having less issues (of course this
also can't work, because you can't use a x86 gdb for arm...)
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1
Copyright (C) 2014 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 "x86_64-linux-gnu".
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 ./vmlinux...done.
(gdb) set debug remote 1
(gdb) set serial baud 115200
(gdb) target remote /dev/ttyUSB4
Remote debugging using /dev/ttyUSB4
Sending packet:
$qSupported:multiprocess+;xmlRegisters=i386;qRelocInsn+#b5...Ack
Packet received:
Packet qSupported (supported-packets) is NOT supported
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $qTStatus#49...Ack
Packet received:
Packet qTStatus (trace-status) is NOT supported
Sending packet: $?#3f...Ack
Packet received: S05
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received: QC0aa8
Sending packet: $qAttached#8f...Ack
Packet received:
Packet qAttached (query-attached) is NOT supported
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $g#67...Ack
Packet received:
0000000001000000b0829e80ac829e8054829880b4a698806700000013000060060000000000000000000000cc3e27bed03e27bec03e27be10200a80581f0a8000000000000000000000000000000000000000000000000000000000000000000000000000000000
Sending packet: $m6,1#00...Ack
Packet received: E22
Sending packet: $m0,40#2d...Ack
Packet received: E22
0x00000006 in __vectors_start () at arch/arm/kernel/entry-armv.S:1138
1138    arch/arm/kernel/entry-armv.S: No such file or directory.
Sending packet: $qSymbol::#5b...Ack
Packet received:
Packet qSymbol (symbol-lookup) is NOT supported
(gdb)

On Fri, Nov 1, 2019 at 1:54 PM Reinoud Koornstra <reinoudkoornstra@gmail.com>
wrote:

>
> [SNIP]
>
>> This is not great.
>>
>> If the debugging stub doesn't support qSupported, then it means GDB will
>> need to guess what the stub's register set is, and that can be tricky.
>>
>> Do you know what register set the debugging stub is using?
>>
>> I need to do some reading if I can see more about the register set and
> see if I can see the whole transmission over serial to verify whether the
> packet is truncated or not.
> let me try to find out and get back to you.
> Thanks, Reinoud.
>
>
>> > Sending packet: $vMustReplyEmpty#3a...Ack
>> > Packet received:
>> > Sending packet: $Hg0#df...Ack
>> > Packet received: OK
>> > Sending packet: $qTStatus#49...Ack
>> > Packet received:
>> > Packet qTStatus (trace-status) is NOT supported
>> > Sending packet: $?#3f...Ack
>> > Packet received: S05
>> > Sending packet: $qfThreadInfo#bb...Ack
>> > Packet received:
>> > mfffffffe,fffffffd,01,02,03,05,06,07,08,09,0a,0b,0c,0d,0e,0f,10,11,12
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> >
>> m0147,014a,014c,0164,016f,0198,01a3,01a9,01dc,01ea,04b3,0502,0511,0512,0513,0514,0515
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> >
>> m0523,0524,0525,0535,0540,0548,0614,098d,0992,0993,09bf,09c2,09c8,09cd,09ce,09db,09e1
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> >
>> m09ea,09f7,09ff,0a36,0a3e,0a4b,0a51,0a57,0a58,0a5a,0a5b,0a5d,0a5e,0a5f,0aa4,0aa6,0aa8
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> >
>> m0af2,0af3,0af4,0afa,0afc,0b7d,0b9a,0b9b,0b9c,0c1d,0cb8,0b96,0be9,0beb,0bf7,0bfb,0bfc
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> >
>> m0bfd,0bfe,0bff,0c00,0c01,0c02,0c03,0c04,0c05,0c06,0c60,0c65,0c67,0c68,0c6d,0c6e,0c7c
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> >
>> m0c7d,0c7f,0ce5,0df6,0e2f,0e39,0e3b,0e3d,0e5d,0e3e,0e3f,0e41,0e8c,0e8e,0ea3,0eaf,0ebc
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> >
>> m0ebe,0ebf,0ec1,0ec2,0ec5,0ec7,0ec9,0ed0,0ed3,0ed4,0eca,0ecc,0ece,0ecf,0ed2,0edc,1061
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> >
>> m1105,13fb,144c,145a,14b6,14c8,14cd,14e0,14f4,150b,1510,1511,1512,1514,1699,169b,169d
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> >
>> m169e,169f,16a0,16a1,16a2,16cd,16cf,16d1,16d2,16d3,16d7,16dd,16de,16df,16e0,16e1,16e2
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> >
>> m16e3,16e4,16e6,1961,1c81,1c82,1c83,1c84,1c85,1c86,1c87,16f2,16f3,16f5,16f6,16fc,1758
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> >
>> m1759,175a,16f7,16f8,16fa,1704,1706,1719,1723,1724,1725,1734,1735,1741,1744,1747,1877
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> >
>> m187b,187d,1880,188f,1893,193b,1949,194a,194f,1952,1957,1a78,1c75,1c77,1c9d,1eb4,1eb6
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> > m1eb8,1ebe,29ed,0149,096c,1334,184d,1df6,1f3f,2123,2165,2175,2183
>> > Sending packet: $qsThreadInfo#c8...Ack
>> > Packet received:
>> > Sending packet: $qAttached#8f...Ack
>> > Packet received:
>> > Packet qAttached (query-attached) is NOT supported
>> > Sending packet: $Hc-1#09...Ack
>> > Packet received: OK
>> > Sending packet: $qC#b4...Ack
>> > Packet received: QC0aa8
>> > Sending packet: $qOffsets#4b...Ack
>> > Packet received:
>> > Sending packet: $g#67...Ack
>> > Packet received:
>> >
>> 0000000001000000b0829e80ac829e8054829880b4a698806700000013000060060000000000000000000000cc3e27bed03e27bec03e27be10200a80581f0a8000000000000000000000000000000000000000000000000000000000000000000000000000000000
>> > Truncated register 19 in remote 'g' packet
>>
>> Could you verify if there is real truncation in the data transmission?
>> Do you have access to what the debugging stub is sending?
>>
>

Re: gdb 8.3.1 truncated register in remote g packet

[Luis Machado]

Hi,

On 11/1/19 6:05 PM, Reinoud Koornstra wrote:
> Hi Luis,
> The remote platform is arm32. Weirdly enough, when I use a gdb 7.7 
> compiled only for x86_64, it does seem to work a bit better, no clue 
> exactly why.

I'm not sure why an arm-targeted gdb would not complain about loading a 
x86-target vmlinux image. That sounds off.

You could try with an older arm gdb to see if it works fine. If it does 
and the latest version doesn't, then we may need to investigate it.

I checked the code and the truncation message is a result of the 
debugging stub sending less bytes than GDB expects for the register set.

Just to confirm, does your arm target have floating point registers?

Re: gdb 8.3.1 truncated register in remote g packet

[Reinoud Koornstra]

>
>
> I'm not sure why an arm-targeted gdb would not complain about loading a
> x86-target vmlinux image. That sounds off.
>
> The vmlinux was compiled for arm, the thing that surprised me that the x64
gdb didn't complain about it. The arm gdb didn't complain either which was
logical.


> You could try with an older arm gdb to see if it works fine. If it does
> and the latest version doesn't, then we may need to investigate it.
>
Ok, I'll compile and older gdb for arm and let you know.

>
> I checked the code and the truncation message is a result of the
> debugging stub sending less bytes than GDB expects for the register set.
>
> The interesting thing is that the incompatible gdb for x86-64 was able to
read the message and the gdb for arm wasn't, but i'll try with an older gdb
for arm, but it's weird.


> Just to confirm, does your arm target have floating point registers?
>
Good point, I did assume it has, because in some cases armeabihf was used
to compile, but not in all cases, I'll check whether it is, otherwise I'd
have to recompile gdb without hf.
I'll get the info and let you know, thanks for helping out!

Reinoud.

Re: gdb 8.3.1 truncated register in remote g packet

[Luis Machado]

On 11/2/19 9:07 PM, Reinoud Koornstra wrote:
> 
> 
> 
>     I'm not sure why an arm-targeted gdb would not complain about loading a
>     x86-target vmlinux image. That sounds off.
> 
> The vmlinux was compiled for arm, the thing that surprised me that the 
> x64 gdb didn't complain about it. The arm gdb didn't complain either 
> which was logical.
> 
>     You could try with an older arm gdb to see if it works fine. If it does
>     and the latest version doesn't, then we may need to investigate it.
> 
> Ok, I'll compile and older gdb for arm and let you know.
> 
> 
>     I checked the code and the truncation message is a result of the
>     debugging stub sending less bytes than GDB expects for the register set.
> 
> The interesting thing is that the incompatible gdb for x86-64 was able 
> to read the message and the gdb for arm wasn't, but i'll try with an 
> older gdb for arm, but it's weird.

You might have gotten lucky. Or GDB wasn't too restrictive on the checks.

> 
>     Just to confirm, does your arm target have floating point registers?
> 
> Good point, I did assume it has, because in some cases armeabihf was 
> used to compile, but not in all cases, I'll check whether it is, 
> otherwise I'd have to recompile gdb without hf.
> I'll get the info and let you know, thanks for helping out!

Well, it seems GDB assumes floating point registers are there by 
default, so there wouldn't be a need to build GDB specifically for that.

Re: gdb 8.3.1 truncated register in remote g packet

[Reinoud Koornstra]

>
>
> You might have gotten lucky. Or GDB wasn't too restrictive on the checks.
>

True

>
> >
> >     Just to confirm, does your arm target have floating point registers?
> >
> > Good point, I did assume it has, because in some cases armeabihf was
> > used to compile, but not in all cases, I'll check whether it is,
> > otherwise I'd have to recompile gdb without hf.
> > I'll get the info and let you know, thanks for helping out!
>

Yes, the arm cpu used has floating point registers


Well, it seems GDB assumes floating point registers are there by
> default, so there wouldn't be a need to build GDB specifically for that.
>

I did compile a gdb 7.7.1,  i compiled earlier 7.0 (failed to compile
without removing Werror in bfd directory Makefile...), then I tried 7.4.1,
but both of these versions didn't support remote baud rate. However 7.7.1
worked nicely, well way better: (I did go echo g > /proc/sysrq-trigger to
get it waiting for gdb).
GNU gdb (GDB) 7.7.1
Copyright (C) 2014 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=arm-linux-gnueabihf".
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 ./vmlinux...done.
(gdb) set serial baud 115200
(gdb) set debug remote 1
(gdb) target remote /dev/ttyUSB4
Remote debugging using /dev/ttyUSB4
Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack
Packet received:
Packet qSupported (supported-packets) is NOT supported
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $qTStatus#49...Ack
Packet received:
Packet qTStatus (trace-status) is NOT supported
Sending packet: $?#3f...Ack
Packet received: S05
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received: QC1fbb
Sending packet: $qAttached#8f...Ack
Packet received:
Packet qAttached (query-attached) is NOT supported
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $g#67...Ack
Packet received:
0000000001000000b0829e80ac829e8054829880b4a698806700000013000060060000000000000000000000cc5e0bbfd05e0bbfc05e0bbf10200a80581f0a8000000000000000000000000000000000000000000000000000000000000000000000000000000000
Sending packet: $m800a1f58,4#ca...Ack
Packet received: ffdeffe7
Sending packet: $m800a1f54,4#c6...Ack
Packet received: 4ef07ff5
Sending packet: $m800a1f58,4#ca...Ack
Packet received: ffdeffe7
Sending packet: $m800a1f54,4#c6...Ack
Packet received: 4ef07ff5
Sending packet: $m800a1f58,4#ca...Ack
Packet received: ffdeffe7
Sending packet: $m800a1f54,4#c6...Ack
Packet received: 4ef07ff5
Sending packet: $m800a1f58,4#ca...Ack
Packet received: ffdeffe7
Sending packet: $m800a1f54,4#c6...Ack
Packet received: 4ef07ff5
Sending packet: $m800a1f58,4#ca...Ack
Packet received: ffdeffe7
Sending packet: $m800a1f58,4#ca...Ack
Packet received: ffdeffe7
Sending packet: $m800a1f58,4#ca...Ack
Packet received: ffdeffe7
0x800a1f58 in arch_kgdb_breakpoint () at kernel/debug/debug_core.c:1049
1049    kernel/debug/debug_core.c: No such file or directory.
Sending packet: $qSymbol::#5b...Ack
Packet received:
Packet qSymbol (symbol-lookup) is NOT supported
(gdb) set debug remote 0
(gdb) bt full
#0  0x800a1f58 in arch_kgdb_breakpoint () at kernel/debug/debug_core.c:1049
No locals.
#1  kgdb_breakpoint () at kernel/debug/debug_core.c:1050
No locals.
#2  0x800a2010 in sysrq_handle_dbg (key=0) at kernel/debug/debug_core.c:810
No locals.
#3  0x80367308 in __handle_sysrq (key=103, check_mask=false) at
drivers/tty/sysrq.c:535
        op_p = 0x8098a6b4 <sysrq_dbg_op>
        orig_log_level = 6
        i = -2137479500
        flags = 1610612755
#4  0x8036745c in write_sysrq_trigger (file=0x0 <__vectors_start>, buf=0x1
<__vectors_start> <error: Cannot access memory at address 0x1>, count=2,
ppos=0x809e82ac <kgdb_use_con>) at drivers/tty/sysrq.c:1083
No locals.
#5  0x80177e18 in proc_reg_write (file=0x0 <__vectors_start>, buf=0x1
<__vectors_start> <error: Cannot access memory at address 0x1>,
count=2157871792, ppos=0xbf0b5f78) at fs/proc/inode.c:224
        write = 0xbf0b5ed0
        rv = 0
#6  0x8011fba4 in vfs_write (file=0xbe37bcc0, buf=0xaa408
"g\nyS0,115200\n", '\337' <repeats 186 times>, <incomplete sequence
\337>..., count=2157871792, pos=0xbf0b5f78) at fs/read_write.c:485
No locals.
#7  0x801201d4 in SYSC_write (count=<optimized out>, buf=<optimized out>,
fd=<optimized out>) at fs/read_write.c:534
        pos = 0
#8  SyS_write (fd=0, buf=697352, count=2) at fs/read_write.c:526
        ret = 0
#9  0x8000f760 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Re: gdb 8.3.1 truncated register in remote g packet

[Luis Machado]

Hi Reinoud,

On 11/4/19 2:52 PM, Reinoud Koornstra wrote:
> 
>     You might have gotten lucky. Or GDB wasn't too restrictive on the
>     checks.
> 
> 
> True
> 
> 
>      >
>      >     Just to confirm, does your arm target have floating point
>     registers?
>      >
>      > Good point, I did assume it has, because in some cases armeabihf was
>      > used to compile, but not in all cases, I'll check whether it is,
>      > otherwise I'd have to recompile gdb without hf.
>      > I'll get the info and let you know, thanks for helping out!
> 
> 
> Yes, the arm cpu used has floating point registers
> 
> 
>     Well, it seems GDB assumes floating point registers are there by
>     default, so there wouldn't be a need to build GDB specifically for that.
> 
> 
> I did compile a gdb 7.7.1,  i compiled earlier 7.0 (failed to compile 
> without removing Werror in bfd directory Makefile...), then I tried 
> 7.4.1, but both of these versions didn't support remote baud rate. 
> However 7.7.1 worked nicely, well way better: (I did go echo g > 
> /proc/sysrq-trigger to get it waiting for gdb).

This indicates something might have changed that made newer GDB's grumpy 
at your kgdb instance.

Would you mind opening a ticket here (https://sourceware.org/bugzilla/) 
so we can track this properly? I'll do some more investigation.

If you don't have an account i can do it for you, from information we 
exchanged through e-mail.

> GNU gdb (GDB) 7.7.1
> Copyright (C) 2014 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=arm-linux-gnueabihf".
> 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 ./vmlinux...done.
> (gdb) set serial baud 115200
> (gdb) set debug remote 1
> (gdb) target remote /dev/ttyUSB4
> Remote debugging using /dev/ttyUSB4
> Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack
> Packet received:
> Packet qSupported (supported-packets) is NOT supported
> Sending packet: $Hg0#df...Ack
> Packet received: OK
> Sending packet: $qTStatus#49...Ack
> Packet received:
> Packet qTStatus (trace-status) is NOT supported
> Sending packet: $?#3f...Ack
> Packet received: S05
> Sending packet: $Hc-1#09...Ack
> Packet received: OK
> Sending packet: $qC#b4...Ack
> Packet received: QC1fbb
> Sending packet: $qAttached#8f...Ack
> Packet received:
> Packet qAttached (query-attached) is NOT supported
> Sending packet: $qOffsets#4b...Ack
> Packet received:
> Sending packet: $g#67...Ack
> Packet received: 
> 0000000001000000b0829e80ac829e8054829880b4a698806700000013000060060000000000000000000000cc5e0bbfd05e0bbfc05e0bbf10200a80581f0a8000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Sending packet: $m800a1f58,4#ca...Ack
> Packet received: ffdeffe7
> Sending packet: $m800a1f54,4#c6...Ack
> Packet received: 4ef07ff5
> Sending packet: $m800a1f58,4#ca...Ack
> Packet received: ffdeffe7
> Sending packet: $m800a1f54,4#c6...Ack
> Packet received: 4ef07ff5
> Sending packet: $m800a1f58,4#ca...Ack
> Packet received: ffdeffe7
> Sending packet: $m800a1f54,4#c6...Ack
> Packet received: 4ef07ff5
> Sending packet: $m800a1f58,4#ca...Ack
> Packet received: ffdeffe7
> Sending packet: $m800a1f54,4#c6...Ack
> Packet received: 4ef07ff5
> Sending packet: $m800a1f58,4#ca...Ack
> Packet received: ffdeffe7
> Sending packet: $m800a1f58,4#ca...Ack
> Packet received: ffdeffe7
> Sending packet: $m800a1f58,4#ca...Ack
> Packet received: ffdeffe7
> 0x800a1f58 in arch_kgdb_breakpoint () at kernel/debug/debug_core.c:1049
> 1049    kernel/debug/debug_core.c: No such file or directory.
> Sending packet: $qSymbol::#5b...Ack
> Packet received:
> Packet qSymbol (symbol-lookup) is NOT supported
> (gdb) set debug remote 0
> (gdb) bt full
> #0  0x800a1f58 in arch_kgdb_breakpoint () at kernel/debug/debug_core.c:1049
> No locals.
> #1  kgdb_breakpoint () at kernel/debug/debug_core.c:1050
> No locals.
> #2  0x800a2010 in sysrq_handle_dbg (key=0) at kernel/debug/debug_core.c:810
> No locals.
> #3  0x80367308 in __handle_sysrq (key=103, check_mask=false) at 
> drivers/tty/sysrq.c:535
>          op_p = 0x8098a6b4 <sysrq_dbg_op>
>          orig_log_level = 6
>          i = -2137479500
>          flags = 1610612755
> #4  0x8036745c in write_sysrq_trigger (file=0x0 <__vectors_start>, 
> buf=0x1 <__vectors_start> <error: Cannot access memory at address 0x1>, 
> count=2, ppos=0x809e82ac <kgdb_use_con>) at drivers/tty/sysrq.c:1083
> No locals.
> #5  0x80177e18 in proc_reg_write (file=0x0 <__vectors_start>, buf=0x1 
> <__vectors_start> <error: Cannot access memory at address 0x1>, 
> count=2157871792, ppos=0xbf0b5f78) at fs/proc/inode.c:224
>          write = 0xbf0b5ed0
>          rv = 0
> #6  0x8011fba4 in vfs_write (file=0xbe37bcc0, buf=0xaa408 
> "g\nyS0,115200\n", '\337' <repeats 186 times>, <incomplete sequence 
> \337>..., count=2157871792, pos=0xbf0b5f78) at fs/read_write.c:485
> No locals.
> #7  0x801201d4 in SYSC_write (count=<optimized out>, buf=<optimized 
> out>, fd=<optimized out>) at fs/read_write.c:534
>          pos = 0
> #8  SyS_write (fd=0, buf=697352, count=2) at fs/read_write.c:526
>          ret = 0
> #9  0x8000f760 in ?? ()
> No symbol table info available.
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Re: gdb 8.3.1 truncated register in remote g packet

[Reinoud Koornstra]

I tried to submit a bug, but it said the info output from gdb I'm trying to
attach is spam and now my account is locked due to spam?.......
Without pasting the gdb output this case doesn't have the info it needs,
but the system thinks it's spam
Thanks, Reinoud.

On Mon, Nov 4, 2019 at 4:50 PM Luis Machado <luis.machado@linaro.org> wrote:

> Hi Reinoud,
>
> On 11/4/19 2:52 PM, Reinoud Koornstra wrote:
> >
> >     You might have gotten lucky. Or GDB wasn't too restrictive on the
> >     checks.
> >
> >
> > True
> >
> >
> >      >
> >      >     Just to confirm, does your arm target have floating point
> >     registers?
> >      >
> >      > Good point, I did assume it has, because in some cases armeabihf
> was
> >      > used to compile, but not in all cases, I'll check whether it is,
> >      > otherwise I'd have to recompile gdb without hf.
> >      > I'll get the info and let you know, thanks for helping out!
> >
> >
> > Yes, the arm cpu used has floating point registers
> >
> >
> >     Well, it seems GDB assumes floating point registers are there by
> >     default, so there wouldn't be a need to build GDB specifically for
> that.
> >
> >
> > I did compile a gdb 7.7.1,  i compiled earlier 7.0 (failed to compile
> > without removing Werror in bfd directory Makefile...), then I tried
> > 7.4.1, but both of these versions didn't support remote baud rate.
> > However 7.7.1 worked nicely, well way better: (I did go echo g >
> > /proc/sysrq-trigger to get it waiting for gdb).
>
> This indicates something might have changed that made newer GDB's grumpy
> at your kgdb instance.
>
> Would you mind opening a ticket here (https://sourceware.org/bugzilla/)
> so we can track this properly? I'll do some more investigation.
>
> If you don't have an account i can do it for you, from information we
> exchanged through e-mail.
>
> > GNU gdb (GDB) 7.7.1
> > Copyright (C) 2014 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=arm-linux-gnueabihf".
> > 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 ./vmlinux...done.
> > (gdb) set serial baud 115200
> > (gdb) set debug remote 1
> > (gdb) target remote /dev/ttyUSB4
> > Remote debugging using /dev/ttyUSB4
> > Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack
> > Packet received:
> > Packet qSupported (supported-packets) is NOT supported
> > Sending packet: $Hg0#df...Ack
> > Packet received: OK
> > Sending packet: $qTStatus#49...Ack
> > Packet received:
> > Packet qTStatus (trace-status) is NOT supported
> > Sending packet: $?#3f...Ack
> > Packet received: S05
> > Sending packet: $Hc-1#09...Ack
> > Packet received: OK
> > Sending packet: $qC#b4...Ack
> > Packet received: QC1fbb
> > Sending packet: $qAttached#8f...Ack
> > Packet received:
> > Packet qAttached (query-attached) is NOT supported
> > Sending packet: $qOffsets#4b...Ack
> > Packet received:
> > Sending packet: $g#67...Ack
> > Packet received:
> >
> 0000000001000000b0829e80ac829e8054829880b4a698806700000013000060060000000000000000000000cc5e0bbfd05e0bbfc05e0bbf10200a80581f0a8000000000000000000000000000000000000000000000000000000000000000000000000000000000
> > Sending packet: $m800a1f58,4#ca...Ack
> > Packet received: ffdeffe7
> > Sending packet: $m800a1f54,4#c6...Ack
> > Packet received: 4ef07ff5
> > Sending packet: $m800a1f58,4#ca...Ack
> > Packet received: ffdeffe7
> > Sending packet: $m800a1f54,4#c6...Ack
> > Packet received: 4ef07ff5
> > Sending packet: $m800a1f58,4#ca...Ack
> > Packet received: ffdeffe7
> > Sending packet: $m800a1f54,4#c6...Ack
> > Packet received: 4ef07ff5
> > Sending packet: $m800a1f58,4#ca...Ack
> > Packet received: ffdeffe7
> > Sending packet: $m800a1f54,4#c6...Ack
> > Packet received: 4ef07ff5
> > Sending packet: $m800a1f58,4#ca...Ack
> > Packet received: ffdeffe7
> > Sending packet: $m800a1f58,4#ca...Ack
> > Packet received: ffdeffe7
> > Sending packet: $m800a1f58,4#ca...Ack
> > Packet received: ffdeffe7
> > 0x800a1f58 in arch_kgdb_breakpoint () at kernel/debug/debug_core.c:1049
> > 1049    kernel/debug/debug_core.c: No such file or directory.
> > Sending packet: $qSymbol::#5b...Ack
> > Packet received:
> > Packet qSymbol (symbol-lookup) is NOT supported
> > (gdb) set debug remote 0
> > (gdb) bt full
> > #0  0x800a1f58 in arch_kgdb_breakpoint () at
> kernel/debug/debug_core.c:1049
> > No locals.
> > #1  kgdb_breakpoint () at kernel/debug/debug_core.c:1050
> > No locals.
> > #2  0x800a2010 in sysrq_handle_dbg (key=0) at
> kernel/debug/debug_core.c:810
> > No locals.
> > #3  0x80367308 in __handle_sysrq (key=103, check_mask=false) at
> > drivers/tty/sysrq.c:535
> >          op_p = 0x8098a6b4 <sysrq_dbg_op>
> >          orig_log_level = 6
> >          i = -2137479500
> >          flags = 1610612755
> > #4  0x8036745c in write_sysrq_trigger (file=0x0 <__vectors_start>,
> > buf=0x1 <__vectors_start> <error: Cannot access memory at address 0x1>,
> > count=2, ppos=0x809e82ac <kgdb_use_con>) at drivers/tty/sysrq.c:1083
> > No locals.
> > #5  0x80177e18 in proc_reg_write (file=0x0 <__vectors_start>, buf=0x1
> > <__vectors_start> <error: Cannot access memory at address 0x1>,
> > count=2157871792, ppos=0xbf0b5f78) at fs/proc/inode.c:224
> >          write = 0xbf0b5ed0
> >          rv = 0
> > #6  0x8011fba4 in vfs_write (file=0xbe37bcc0, buf=0xaa408
> > "g\nyS0,115200\n", '\337' <repeats 186 times>, <incomplete sequence
> > \337>..., count=2157871792, pos=0xbf0b5f78) at fs/read_write.c:485
> > No locals.
> > #7  0x801201d4 in SYSC_write (count=<optimized out>, buf=<optimized
> > out>, fd=<optimized out>) at fs/read_write.c:534
> >          pos = 0
> > #8  SyS_write (fd=0, buf=697352, count=2) at fs/read_write.c:526
> >          ret = 0
> > #9  0x8000f760 in ?? ()
> > No symbol table info available.
> > Backtrace stopped: previous frame identical to this frame (corrupt
> stack?)
>

Re: gdb 8.3.1 truncated register in remote g packet

[Luis Machado]

On 11/5/19 1:05 AM, Reinoud Koornstra wrote:
> I tried to submit a bug, but it said the info output from gdb I'm trying 
> to attach is spam and now my account is locked due to spam?.......
> Without pasting the gdb output this case doesn't have the info it needs, 
> but the system thinks it's spam
> Thanks, Reinoud.

Sorry... That's unfortunate. No worries though, i'll have it created and 
will let you know.

> 
> On Mon, Nov 4, 2019 at 4:50 PM Luis Machado <luis.machado@linaro.org 
> <mailto:luis.machado@linaro.org>> wrote:
> 
>     Hi Reinoud,
> 
>     On 11/4/19 2:52 PM, Reinoud Koornstra wrote:
>      >
>      >     You might have gotten lucky. Or GDB wasn't too restrictive on the
>      >     checks.
>      >
>      >
>      > True
>      >
>      >
>      >      >
>      >      >     Just to confirm, does your arm target have floating point
>      >     registers?
>      >      >
>      >      > Good point, I did assume it has, because in some cases
>     armeabihf was
>      >      > used to compile, but not in all cases, I'll check whether
>     it is,
>      >      > otherwise I'd have to recompile gdb without hf.
>      >      > I'll get the info and let you know, thanks for helping out!
>      >
>      >
>      > Yes, the arm cpu used has floating point registers
>      >
>      >
>      >     Well, it seems GDB assumes floating point registers are there by
>      >     default, so there wouldn't be a need to build GDB
>     specifically for that.
>      >
>      >
>      > I did compile a gdb 7.7.1,  i compiled earlier 7.0 (failed to
>     compile
>      > without removing Werror in bfd directory Makefile...), then I tried
>      > 7.4.1, but both of these versions didn't support remote baud rate.
>      > However 7.7.1 worked nicely, well way better: (I did go echo g >
>      > /proc/sysrq-trigger to get it waiting for gdb).
> 
>     This indicates something might have changed that made newer GDB's
>     grumpy
>     at your kgdb instance.
> 
>     Would you mind opening a ticket here (https://sourceware.org/bugzilla/)
>     so we can track this properly? I'll do some more investigation.
> 
>     If you don't have an account i can do it for you, from information we
>     exchanged through e-mail.
> 
>      > GNU gdb (GDB) 7.7.1
>      > Copyright (C) 2014 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=arm-linux-gnueabihf".
>      > 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 ./vmlinux...done.
>      > (gdb) set serial baud 115200
>      > (gdb) set debug remote 1
>      > (gdb) target remote /dev/ttyUSB4
>      > Remote debugging using /dev/ttyUSB4
>      > Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack
>      > Packet received:
>      > Packet qSupported (supported-packets) is NOT supported
>      > Sending packet: $Hg0#df...Ack
>      > Packet received: OK
>      > Sending packet: $qTStatus#49...Ack
>      > Packet received:
>      > Packet qTStatus (trace-status) is NOT supported
>      > Sending packet: $?#3f...Ack
>      > Packet received: S05
>      > Sending packet: $Hc-1#09...Ack
>      > Packet received: OK
>      > Sending packet: $qC#b4...Ack
>      > Packet received: QC1fbb
>      > Sending packet: $qAttached#8f...Ack
>      > Packet received:
>      > Packet qAttached (query-attached) is NOT supported
>      > Sending packet: $qOffsets#4b...Ack
>      > Packet received:
>      > Sending packet: $g#67...Ack
>      > Packet received:
>      >
>     0000000001000000b0829e80ac829e8054829880b4a698806700000013000060060000000000000000000000cc5e0bbfd05e0bbfc05e0bbf10200a80581f0a8000000000000000000000000000000000000000000000000000000000000000000000000000000000
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > Sending packet: $m800a1f54,4#c6...Ack
>      > Packet received: 4ef07ff5
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > Sending packet: $m800a1f54,4#c6...Ack
>      > Packet received: 4ef07ff5
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > Sending packet: $m800a1f54,4#c6...Ack
>      > Packet received: 4ef07ff5
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > Sending packet: $m800a1f54,4#c6...Ack
>      > Packet received: 4ef07ff5
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > 0x800a1f58 in arch_kgdb_breakpoint () at
>     kernel/debug/debug_core.c:1049
>      > 1049    kernel/debug/debug_core.c: No such file or directory.
>      > Sending packet: $qSymbol::#5b...Ack
>      > Packet received:
>      > Packet qSymbol (symbol-lookup) is NOT supported
>      > (gdb) set debug remote 0
>      > (gdb) bt full
>      > #0  0x800a1f58 in arch_kgdb_breakpoint () at
>     kernel/debug/debug_core.c:1049
>      > No locals.
>      > #1  kgdb_breakpoint () at kernel/debug/debug_core.c:1050
>      > No locals.
>      > #2  0x800a2010 in sysrq_handle_dbg (key=0) at
>     kernel/debug/debug_core.c:810
>      > No locals.
>      > #3  0x80367308 in __handle_sysrq (key=103, check_mask=false) at
>      > drivers/tty/sysrq.c:535
>      >          op_p = 0x8098a6b4 <sysrq_dbg_op>
>      >          orig_log_level = 6
>      >          i = -2137479500
>      >          flags = 1610612755
>      > #4  0x8036745c in write_sysrq_trigger (file=0x0 <__vectors_start>,
>      > buf=0x1 <__vectors_start> <error: Cannot access memory at address
>     0x1>,
>      > count=2, ppos=0x809e82ac <kgdb_use_con>) at drivers/tty/sysrq.c:1083
>      > No locals.
>      > #5  0x80177e18 in proc_reg_write (file=0x0 <__vectors_start>,
>     buf=0x1
>      > <__vectors_start> <error: Cannot access memory at address 0x1>,
>      > count=2157871792, ppos=0xbf0b5f78) at fs/proc/inode.c:224
>      >          write = 0xbf0b5ed0
>      >          rv = 0
>      > #6  0x8011fba4 in vfs_write (file=0xbe37bcc0, buf=0xaa408
>      > "g\nyS0,115200\n", '\337' <repeats 186 times>, <incomplete sequence
>      > \337>..., count=2157871792, pos=0xbf0b5f78) at fs/read_write.c:485
>      > No locals.
>      > #7  0x801201d4 in SYSC_write (count=<optimized out>, buf=<optimized
>      > out>, fd=<optimized out>) at fs/read_write.c:534
>      >          pos = 0
>      > #8  SyS_write (fd=0, buf=697352, count=2) at fs/read_write.c:526
>      >          ret = 0
>      > #9  0x8000f760 in ?? ()
>      > No symbol table info available.
>      > Backtrace stopped: previous frame identical to this frame
>     (corrupt stack?)
> 

Re: gdb 8.3.1 truncated register in remote g packet

[Luis Machado]

I've filed this as https://sourceware.org/bugzilla/show_bug.cgi?id=25162

I'll do some more investigation later and will update the ticket.

On 11/5/19 1:05 AM, Reinoud Koornstra wrote:
> I tried to submit a bug, but it said the info output from gdb I'm trying 
> to attach is spam and now my account is locked due to spam?.......
> Without pasting the gdb output this case doesn't have the info it needs, 
> but the system thinks it's spam
> Thanks, Reinoud.
> 
> On Mon, Nov 4, 2019 at 4:50 PM Luis Machado <luis.machado@linaro.org 
> <mailto:luis.machado@linaro.org>> wrote:
> 
>     Hi Reinoud,
> 
>     On 11/4/19 2:52 PM, Reinoud Koornstra wrote:
>      >
>      >     You might have gotten lucky. Or GDB wasn't too restrictive on the
>      >     checks.
>      >
>      >
>      > True
>      >
>      >
>      >      >
>      >      >     Just to confirm, does your arm target have floating point
>      >     registers?
>      >      >
>      >      > Good point, I did assume it has, because in some cases
>     armeabihf was
>      >      > used to compile, but not in all cases, I'll check whether
>     it is,
>      >      > otherwise I'd have to recompile gdb without hf.
>      >      > I'll get the info and let you know, thanks for helping out!
>      >
>      >
>      > Yes, the arm cpu used has floating point registers
>      >
>      >
>      >     Well, it seems GDB assumes floating point registers are there by
>      >     default, so there wouldn't be a need to build GDB
>     specifically for that.
>      >
>      >
>      > I did compile a gdb 7.7.1,  i compiled earlier 7.0 (failed to
>     compile
>      > without removing Werror in bfd directory Makefile...), then I tried
>      > 7.4.1, but both of these versions didn't support remote baud rate.
>      > However 7.7.1 worked nicely, well way better: (I did go echo g >
>      > /proc/sysrq-trigger to get it waiting for gdb).
> 
>     This indicates something might have changed that made newer GDB's
>     grumpy
>     at your kgdb instance.
> 
>     Would you mind opening a ticket here (https://sourceware.org/bugzilla/)
>     so we can track this properly? I'll do some more investigation.
> 
>     If you don't have an account i can do it for you, from information we
>     exchanged through e-mail.
> 
>      > GNU gdb (GDB) 7.7.1
>      > Copyright (C) 2014 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=arm-linux-gnueabihf".
>      > 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 ./vmlinux...done.
>      > (gdb) set serial baud 115200
>      > (gdb) set debug remote 1
>      > (gdb) target remote /dev/ttyUSB4
>      > Remote debugging using /dev/ttyUSB4
>      > Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack
>      > Packet received:
>      > Packet qSupported (supported-packets) is NOT supported
>      > Sending packet: $Hg0#df...Ack
>      > Packet received: OK
>      > Sending packet: $qTStatus#49...Ack
>      > Packet received:
>      > Packet qTStatus (trace-status) is NOT supported
>      > Sending packet: $?#3f...Ack
>      > Packet received: S05
>      > Sending packet: $Hc-1#09...Ack
>      > Packet received: OK
>      > Sending packet: $qC#b4...Ack
>      > Packet received: QC1fbb
>      > Sending packet: $qAttached#8f...Ack
>      > Packet received:
>      > Packet qAttached (query-attached) is NOT supported
>      > Sending packet: $qOffsets#4b...Ack
>      > Packet received:
>      > Sending packet: $g#67...Ack
>      > Packet received:
>      >
>     0000000001000000b0829e80ac829e8054829880b4a698806700000013000060060000000000000000000000cc5e0bbfd05e0bbfc05e0bbf10200a80581f0a8000000000000000000000000000000000000000000000000000000000000000000000000000000000
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > Sending packet: $m800a1f54,4#c6...Ack
>      > Packet received: 4ef07ff5
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > Sending packet: $m800a1f54,4#c6...Ack
>      > Packet received: 4ef07ff5
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > Sending packet: $m800a1f54,4#c6...Ack
>      > Packet received: 4ef07ff5
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > Sending packet: $m800a1f54,4#c6...Ack
>      > Packet received: 4ef07ff5
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > Sending packet: $m800a1f58,4#ca...Ack
>      > Packet received: ffdeffe7
>      > 0x800a1f58 in arch_kgdb_breakpoint () at
>     kernel/debug/debug_core.c:1049
>      > 1049    kernel/debug/debug_core.c: No such file or directory.
>      > Sending packet: $qSymbol::#5b...Ack
>      > Packet received:
>      > Packet qSymbol (symbol-lookup) is NOT supported
>      > (gdb) set debug remote 0
>      > (gdb) bt full
>      > #0  0x800a1f58 in arch_kgdb_breakpoint () at
>     kernel/debug/debug_core.c:1049
>      > No locals.
>      > #1  kgdb_breakpoint () at kernel/debug/debug_core.c:1050
>      > No locals.
>      > #2  0x800a2010 in sysrq_handle_dbg (key=0) at
>     kernel/debug/debug_core.c:810
>      > No locals.
>      > #3  0x80367308 in __handle_sysrq (key=103, check_mask=false) at
>      > drivers/tty/sysrq.c:535
>      >          op_p = 0x8098a6b4 <sysrq_dbg_op>
>      >          orig_log_level = 6
>      >          i = -2137479500
>      >          flags = 1610612755
>      > #4  0x8036745c in write_sysrq_trigger (file=0x0 <__vectors_start>,
>      > buf=0x1 <__vectors_start> <error: Cannot access memory at address
>     0x1>,
>      > count=2, ppos=0x809e82ac <kgdb_use_con>) at drivers/tty/sysrq.c:1083
>      > No locals.
>      > #5  0x80177e18 in proc_reg_write (file=0x0 <__vectors_start>,
>     buf=0x1
>      > <__vectors_start> <error: Cannot access memory at address 0x1>,
>      > count=2157871792, ppos=0xbf0b5f78) at fs/proc/inode.c:224
>      >          write = 0xbf0b5ed0
>      >          rv = 0
>      > #6  0x8011fba4 in vfs_write (file=0xbe37bcc0, buf=0xaa408
>      > "g\nyS0,115200\n", '\337' <repeats 186 times>, <incomplete sequence
>      > \337>..., count=2157871792, pos=0xbf0b5f78) at fs/read_write.c:485
>      > No locals.
>      > #7  0x801201d4 in SYSC_write (count=<optimized out>, buf=<optimized
>      > out>, fd=<optimized out>) at fs/read_write.c:534
>      >          pos = 0
>      > #8  SyS_write (fd=0, buf=697352, count=2) at fs/read_write.c:526
>      >          ret = 0
>      > #9  0x8000f760 in ?? ()
>      > No symbol table info available.
>      > Backtrace stopped: previous frame identical to this frame
>     (corrupt stack?)
> 

Re: gdb 8.3.1 truncated register in remote g packet

[Reinoud Koornstra]

Thanks Luis,
I'm very interested what you'll find.
Thanks, Reinoud.

On Tue, Nov 5, 2019 at 4:49 AM Luis Machado <luis.machado@linaro.org> wrote:

> I've filed this as https://sourceware.org/bugzilla/show_bug.cgi?id=25162
>
> I'll do some more investigation later and will update the ticket.
>
> On 11/5/19 1:05 AM, Reinoud Koornstra wrote:
> > I tried to submit a bug, but it said the info output from gdb I'm trying
> > to attach is spam and now my account is locked due to spam?.......
> > Without pasting the gdb output this case doesn't have the info it needs,
> > but the system thinks it's spam
> > Thanks, Reinoud.
> >
> > On Mon, Nov 4, 2019 at 4:50 PM Luis Machado <luis.machado@linaro.org
> > <mailto:luis.machado@linaro.org>> wrote:
> >
> >     Hi Reinoud,
> >
> >     On 11/4/19 2:52 PM, Reinoud Koornstra wrote:
> >      >
> >      >     You might have gotten lucky. Or GDB wasn't too restrictive on
> the
> >      >     checks.
> >      >
> >      >
> >      > True
> >      >
> >      >
> >      >      >
> >      >      >     Just to confirm, does your arm target have floating
> point
> >      >     registers?
> >      >      >
> >      >      > Good point, I did assume it has, because in some cases
> >     armeabihf was
> >      >      > used to compile, but not in all cases, I'll check whether
> >     it is,
> >      >      > otherwise I'd have to recompile gdb without hf.
> >      >      > I'll get the info and let you know, thanks for helping out!
> >      >
> >      >
> >      > Yes, the arm cpu used has floating point registers
> >      >
> >      >
> >      >     Well, it seems GDB assumes floating point registers are there
> by
> >      >     default, so there wouldn't be a need to build GDB
> >     specifically for that.
> >      >
> >      >
> >      > I did compile a gdb 7.7.1,  i compiled earlier 7.0 (failed to
> >     compile
> >      > without removing Werror in bfd directory Makefile...), then I
> tried
> >      > 7.4.1, but both of these versions didn't support remote baud rate.
> >      > However 7.7.1 worked nicely, well way better: (I did go echo g >
> >      > /proc/sysrq-trigger to get it waiting for gdb).
> >
> >     This indicates something might have changed that made newer GDB's
> >     grumpy
> >     at your kgdb instance.
> >
> >     Would you mind opening a ticket here (
> https://sourceware.org/bugzilla/)
> >     so we can track this properly? I'll do some more investigation.
> >
> >     If you don't have an account i can do it for you, from information we
> >     exchanged through e-mail.
> >
> >      > GNU gdb (GDB) 7.7.1
> >      > Copyright (C) 2014 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=arm-linux-gnueabihf".
> >      > 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 ./vmlinux...done.
> >      > (gdb) set serial baud 115200
> >      > (gdb) set debug remote 1
> >      > (gdb) target remote /dev/ttyUSB4
> >      > Remote debugging using /dev/ttyUSB4
> >      > Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack
> >      > Packet received:
> >      > Packet qSupported (supported-packets) is NOT supported
> >      > Sending packet: $Hg0#df...Ack
> >      > Packet received: OK
> >      > Sending packet: $qTStatus#49...Ack
> >      > Packet received:
> >      > Packet qTStatus (trace-status) is NOT supported
> >      > Sending packet: $?#3f...Ack
> >      > Packet received: S05
> >      > Sending packet: $Hc-1#09...Ack
> >      > Packet received: OK
> >      > Sending packet: $qC#b4...Ack
> >      > Packet received: QC1fbb
> >      > Sending packet: $qAttached#8f...Ack
> >      > Packet received:
> >      > Packet qAttached (query-attached) is NOT supported
> >      > Sending packet: $qOffsets#4b...Ack
> >      > Packet received:
> >      > Sending packet: $g#67...Ack
> >      > Packet received:
> >      >
> >
>  0000000001000000b0829e80ac829e8054829880b4a698806700000013000060060000000000000000000000cc5e0bbfd05e0bbfc05e0bbf10200a80581f0a8000000000000000000000000000000000000000000000000000000000000000000000000000000000
> >      > Sending packet: $m800a1f58,4#ca...Ack
> >      > Packet received: ffdeffe7
> >      > Sending packet: $m800a1f54,4#c6...Ack
> >      > Packet received: 4ef07ff5
> >      > Sending packet: $m800a1f58,4#ca...Ack
> >      > Packet received: ffdeffe7
> >      > Sending packet: $m800a1f54,4#c6...Ack
> >      > Packet received: 4ef07ff5
> >      > Sending packet: $m800a1f58,4#ca...Ack
> >      > Packet received: ffdeffe7
> >      > Sending packet: $m800a1f54,4#c6...Ack
> >      > Packet received: 4ef07ff5
> >      > Sending packet: $m800a1f58,4#ca...Ack
> >      > Packet received: ffdeffe7
> >      > Sending packet: $m800a1f54,4#c6...Ack
> >      > Packet received: 4ef07ff5
> >      > Sending packet: $m800a1f58,4#ca...Ack
> >      > Packet received: ffdeffe7
> >      > Sending packet: $m800a1f58,4#ca...Ack
> >      > Packet received: ffdeffe7
> >      > Sending packet: $m800a1f58,4#ca...Ack
> >      > Packet received: ffdeffe7
> >      > 0x800a1f58 in arch_kgdb_breakpoint () at
> >     kernel/debug/debug_core.c:1049
> >      > 1049    kernel/debug/debug_core.c: No such file or directory.
> >      > Sending packet: $qSymbol::#5b...Ack
> >      > Packet received:
> >      > Packet qSymbol (symbol-lookup) is NOT supported
> >      > (gdb) set debug remote 0
> >      > (gdb) bt full
> >      > #0  0x800a1f58 in arch_kgdb_breakpoint () at
> >     kernel/debug/debug_core.c:1049
> >      > No locals.
> >      > #1  kgdb_breakpoint () at kernel/debug/debug_core.c:1050
> >      > No locals.
> >      > #2  0x800a2010 in sysrq_handle_dbg (key=0) at
> >     kernel/debug/debug_core.c:810
> >      > No locals.
> >      > #3  0x80367308 in __handle_sysrq (key=103, check_mask=false) at
> >      > drivers/tty/sysrq.c:535
> >      >          op_p = 0x8098a6b4 <sysrq_dbg_op>
> >      >          orig_log_level = 6
> >      >          i = -2137479500
> >      >          flags = 1610612755
> >      > #4  0x8036745c in write_sysrq_trigger (file=0x0 <__vectors_start>,
> >      > buf=0x1 <__vectors_start> <error: Cannot access memory at address
> >     0x1>,
> >      > count=2, ppos=0x809e82ac <kgdb_use_con>) at
> drivers/tty/sysrq.c:1083
> >      > No locals.
> >      > #5  0x80177e18 in proc_reg_write (file=0x0 <__vectors_start>,
> >     buf=0x1
> >      > <__vectors_start> <error: Cannot access memory at address 0x1>,
> >      > count=2157871792, ppos=0xbf0b5f78) at fs/proc/inode.c:224
> >      >          write = 0xbf0b5ed0
> >      >          rv = 0
> >      > #6  0x8011fba4 in vfs_write (file=0xbe37bcc0, buf=0xaa408
> >      > "g\nyS0,115200\n", '\337' <repeats 186 times>, <incomplete
> sequence
> >      > \337>..., count=2157871792, pos=0xbf0b5f78) at fs/read_write.c:485
> >      > No locals.
> >      > #7  0x801201d4 in SYSC_write (count=<optimized out>,
> buf=<optimized
> >      > out>, fd=<optimized out>) at fs/read_write.c:534
> >      >          pos = 0
> >      > #8  SyS_write (fd=0, buf=697352, count=2) at fs/read_write.c:526
> >      >          ret = 0
> >      > #9  0x8000f760 in ?? ()
> >      > No symbol table info available.
> >      > Backtrace stopped: previous frame identical to this frame
> >     (corrupt stack?)
> >
>