* gdb 8.3.1 truncated register in remote g packet
@ 2019-10-31 18:58 Reinoud Koornstra
2019-11-01 16:11 ` Luis Machado
0 siblings, 1 reply; 15+ messages in thread
From: Reinoud Koornstra @ 2019-10-31 18:58 UTC (permalink / raw)
To: gdb
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-10-31 18:58 gdb 8.3.1 truncated register in remote g packet Reinoud Koornstra
@ 2019-11-01 16:11 ` Luis Machado
2019-11-01 18:24 ` Reinoud Koornstra
0 siblings, 1 reply; 15+ messages in thread
From: Luis Machado @ 2019-11-01 16:11 UTC (permalink / raw)
To: Reinoud Koornstra, gdb
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.
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-11-01 16:11 ` Luis Machado
@ 2019-11-01 18:24 ` Reinoud Koornstra
2019-11-01 20:27 ` Luis Machado
0 siblings, 1 reply; 15+ messages in thread
From: Reinoud Koornstra @ 2019-11-01 18:24 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-11-01 18:24 ` Reinoud Koornstra
@ 2019-11-01 20:27 ` Luis Machado
2019-11-01 20:55 ` Reinoud Koornstra
0 siblings, 1 reply; 15+ messages in thread
From: Luis Machado @ 2019-11-01 20:27 UTC (permalink / raw)
To: Reinoud Koornstra; +Cc: gdb
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?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-11-01 20:27 ` Luis Machado
@ 2019-11-01 20:55 ` Reinoud Koornstra
2019-11-01 21:05 ` Reinoud Koornstra
0 siblings, 1 reply; 15+ messages in thread
From: Reinoud Koornstra @ 2019-11-01 20:55 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb
[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?
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-11-01 20:55 ` Reinoud Koornstra
@ 2019-11-01 21:05 ` Reinoud Koornstra
2019-11-02 1:30 ` Luis Machado
0 siblings, 1 reply; 15+ messages in thread
From: Reinoud Koornstra @ 2019-11-01 21:05 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb
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?
>>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-11-01 21:05 ` Reinoud Koornstra
@ 2019-11-02 1:30 ` Luis Machado
2019-11-03 0:07 ` Reinoud Koornstra
0 siblings, 1 reply; 15+ messages in thread
From: Luis Machado @ 2019-11-02 1:30 UTC (permalink / raw)
To: Reinoud Koornstra; +Cc: gdb
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?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-11-02 1:30 ` Luis Machado
@ 2019-11-03 0:07 ` Reinoud Koornstra
2019-11-04 14:48 ` Luis Machado
0 siblings, 1 reply; 15+ messages in thread
From: Reinoud Koornstra @ 2019-11-03 0:07 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb
>
>
> 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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-11-03 0:07 ` Reinoud Koornstra
@ 2019-11-04 14:48 ` Luis Machado
2019-11-04 17:53 ` Reinoud Koornstra
0 siblings, 1 reply; 15+ messages in thread
From: Luis Machado @ 2019-11-04 14:48 UTC (permalink / raw)
To: Reinoud Koornstra; +Cc: gdb
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-11-04 14:48 ` Luis Machado
@ 2019-11-04 17:53 ` Reinoud Koornstra
2019-11-05 0:50 ` Luis Machado
0 siblings, 1 reply; 15+ messages in thread
From: Reinoud Koornstra @ 2019-11-04 17:53 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb
>
>
> 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?)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-11-04 17:53 ` Reinoud Koornstra
@ 2019-11-05 0:50 ` Luis Machado
2019-11-05 4:05 ` Reinoud Koornstra
0 siblings, 1 reply; 15+ messages in thread
From: Luis Machado @ 2019-11-05 0:50 UTC (permalink / raw)
To: Reinoud Koornstra; +Cc: gdb
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?)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-11-05 0:50 ` Luis Machado
@ 2019-11-05 4:05 ` Reinoud Koornstra
2019-11-05 11:33 ` Luis Machado
2019-11-05 12:49 ` Luis Machado
0 siblings, 2 replies; 15+ messages in thread
From: Reinoud Koornstra @ 2019-11-05 4:05 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb
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?)
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-11-05 4:05 ` Reinoud Koornstra
@ 2019-11-05 11:33 ` Luis Machado
2019-11-05 12:49 ` Luis Machado
1 sibling, 0 replies; 15+ messages in thread
From: Luis Machado @ 2019-11-05 11:33 UTC (permalink / raw)
To: Reinoud Koornstra; +Cc: gdb
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?)
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-11-05 4:05 ` Reinoud Koornstra
2019-11-05 11:33 ` Luis Machado
@ 2019-11-05 12:49 ` Luis Machado
2019-11-05 18:50 ` Reinoud Koornstra
1 sibling, 1 reply; 15+ messages in thread
From: Luis Machado @ 2019-11-05 12:49 UTC (permalink / raw)
To: Reinoud Koornstra; +Cc: gdb
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?)
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb 8.3.1 truncated register in remote g packet
2019-11-05 12:49 ` Luis Machado
@ 2019-11-05 18:50 ` Reinoud Koornstra
0 siblings, 0 replies; 15+ messages in thread
From: Reinoud Koornstra @ 2019-11-05 18:50 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb
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?)
> >
>
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-11-05 18:50 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-31 18:58 gdb 8.3.1 truncated register in remote g packet Reinoud Koornstra
2019-11-01 16:11 ` Luis Machado
2019-11-01 18:24 ` Reinoud Koornstra
2019-11-01 20:27 ` Luis Machado
2019-11-01 20:55 ` Reinoud Koornstra
2019-11-01 21:05 ` Reinoud Koornstra
2019-11-02 1:30 ` Luis Machado
2019-11-03 0:07 ` Reinoud Koornstra
2019-11-04 14:48 ` Luis Machado
2019-11-04 17:53 ` Reinoud Koornstra
2019-11-05 0:50 ` Luis Machado
2019-11-05 4:05 ` Reinoud Koornstra
2019-11-05 11:33 ` Luis Machado
2019-11-05 12:49 ` Luis Machado
2019-11-05 18:50 ` Reinoud Koornstra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox