Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Luis Machado <luis.machado@linaro.org>
To: Reinoud Koornstra <reinoudkoornstra@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: gdb 8.3.1 truncated register in remote g packet
Date: Tue, 05 Nov 2019 12:49:00 -0000	[thread overview]
Message-ID: <07d83d2b-ed85-d97a-f071-74d383cd5986@linaro.org> (raw)
In-Reply-To: <CAAA5faE+J3TFLF3zbQnKuL+EBp9hDoFjxiMLayZmaY-7e2qg5w@mail.gmail.com>

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?)
> 


  parent reply	other threads:[~2019-11-05 12:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-31 18:58 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 [this message]
2019-11-05 18:50                         ` Reinoud Koornstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=07d83d2b-ed85-d97a-f071-74d383cd5986@linaro.org \
    --to=luis.machado@linaro.org \
    --cc=gdb@sourceware.org \
    --cc=reinoudkoornstra@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox