* Debug with gdbserver @ 2012-08-01 2:46 Darren Hart 2012-08-01 3:13 ` Khem Raj 0 siblings, 1 reply; 10+ messages in thread From: Darren Hart @ 2012-08-01 2:46 UTC (permalink / raw) To: Zhang, Jessica, Yocto Project I am trying to debug a userpsace application that misbehaves under poky-tiny. My current approach is use gdbserver on the target and attach to the offending process, then connect to it on the client using the yocto-built native gdb for the target. I can easily add gdbserver to the target image, and can successfully connect it to the process: # From the target (qemux86) root shell: # dropbearkey -t rsa -f ./rsa # dropbear -r ./rsa # DBPID=$(ps | grep dropbear | head -n1 | cut -f4 -d ' ') # gdbserver 127.0.0.1:1234 --attach $DBPID Now on the host machine (amd64) I want to: $ gdb???? (gdb) target extended-remote 127.0.0.1:1234 Which package do I need to build to get the appropriate gdb for the host to remote debug processes on the target? -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Debug with gdbserver 2012-08-01 2:46 Debug with gdbserver Darren Hart @ 2012-08-01 3:13 ` Khem Raj 2012-08-01 3:47 ` Darren Hart 0 siblings, 1 reply; 10+ messages in thread From: Khem Raj @ 2012-08-01 3:13 UTC (permalink / raw) To: Darren Hart; +Cc: Yocto Project On Jul 31, 2012, at 7:46 PM, Darren Hart <dvhart@linux.intel.com> wrote: > I am trying to debug a userpsace application that misbehaves under > poky-tiny. My current approach is use gdbserver on the target and attach > to the offending process, then connect to it on the client using the > yocto-built native gdb for the target. > > I can easily add gdbserver to the target image, and can successfully > connect it to the process: > > # From the target (qemux86) root shell: > # dropbearkey -t rsa -f ./rsa > # dropbear -r ./rsa > # DBPID=$(ps | grep dropbear | head -n1 | cut -f4 -d ' ') > # gdbserver 127.0.0.1:1234 --attach $DBPID > > Now on the host machine (amd64) I want to: > $ gdb???? > (gdb) target extended-remote 127.0.0.1:1234 > > Which package do I need to build to get the appropriate gdb for the host > to remote debug processes on the target? bake cross-gdb for your arch and use it same way as above > -- > Darren Hart > Intel Open Source Technology Center > Yocto Project - Technical Lead - Linux Kernel > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Debug with gdbserver 2012-08-01 3:13 ` Khem Raj @ 2012-08-01 3:47 ` Darren Hart 2012-08-01 4:55 ` Khem Raj 2012-08-01 6:15 ` Martin Jansa 0 siblings, 2 replies; 10+ messages in thread From: Darren Hart @ 2012-08-01 3:47 UTC (permalink / raw) To: Khem Raj; +Cc: Yocto Project On 07/31/2012 08:13 PM, Khem Raj wrote: > > On Jul 31, 2012, at 7:46 PM, Darren Hart <dvhart@linux.intel.com> wrote: > >> I am trying to debug a userpsace application that misbehaves under >> poky-tiny. My current approach is use gdbserver on the target and attach >> to the offending process, then connect to it on the client using the >> yocto-built native gdb for the target. >> >> I can easily add gdbserver to the target image, and can successfully >> connect it to the process: >> >> # From the target (qemux86) root shell: >> # dropbearkey -t rsa -f ./rsa >> # dropbear -r ./rsa >> # DBPID=$(ps | grep dropbear | head -n1 | cut -f4 -d ' ') >> # gdbserver 127.0.0.1:1234 --attach $DBPID >> >> Now on the host machine (amd64) I want to: >> $ gdb???? >> (gdb) target extended-remote 127.0.0.1:1234 >> >> Which package do I need to build to get the appropriate gdb for the host >> to remote debug processes on the target? > > bake cross-gdb for your arch and use it same way as above ERROR: Nothing PROVIDES 'cross-gdb' gdb-cross maybe? Ah that gets a lot farther... and then do_compile fails. | libgdb.a(python.o): In function `gdbpy_target_wide_charset': | python.c:(.text+0x1c7): undefined reference to `PyUnicodeUCS4_Decode' And a lot more similar to that. I'm doing this on poky-tiny (so a minimal target libc... shouldn't impact native bits though right? Will beat on it some more in the morning. -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Debug with gdbserver 2012-08-01 3:47 ` Darren Hart @ 2012-08-01 4:55 ` Khem Raj 2012-08-01 6:15 ` Martin Jansa 1 sibling, 0 replies; 10+ messages in thread From: Khem Raj @ 2012-08-01 4:55 UTC (permalink / raw) To: Darren Hart; +Cc: Yocto Project On Jul 31, 2012, at 8:47 PM, Darren Hart <dvhart@linux.intel.com> wrote: > > > On 07/31/2012 08:13 PM, Khem Raj wrote: >> >> On Jul 31, 2012, at 7:46 PM, Darren Hart <dvhart@linux.intel.com> wrote: >> >>> I am trying to debug a userpsace application that misbehaves under >>> poky-tiny. My current approach is use gdbserver on the target and attach >>> to the offending process, then connect to it on the client using the >>> yocto-built native gdb for the target. >>> >>> I can easily add gdbserver to the target image, and can successfully >>> connect it to the process: >>> >>> # From the target (qemux86) root shell: >>> # dropbearkey -t rsa -f ./rsa >>> # dropbear -r ./rsa >>> # DBPID=$(ps | grep dropbear | head -n1 | cut -f4 -d ' ') >>> # gdbserver 127.0.0.1:1234 --attach $DBPID >>> >>> Now on the host machine (amd64) I want to: >>> $ gdb???? >>> (gdb) target extended-remote 127.0.0.1:1234 >>> >>> Which package do I need to build to get the appropriate gdb for the host >>> to remote debug processes on the target? >> >> bake cross-gdb for your arch and use it same way as above > > ERROR: Nothing PROVIDES 'cross-gdb' > > gdb-cross maybe? > I meant cross gdb not the exact recipe name :) > Ah that gets a lot farther... and then do_compile fails. > > | libgdb.a(python.o): In function `gdbpy_target_wide_charset': > | python.c:(.text+0x1c7): undefined reference to `PyUnicodeUCS4_Decode' > > And a lot more similar to that. I'm doing this on poky-tiny (so a > minimal target libc... shouldn't impact native bits though right? shouldn't it seems you need python native > > > Will beat on it some more in the morning. > > -- > Darren Hart > Intel Open Source Technology Center > Yocto Project - Technical Lead - Linux Kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Debug with gdbserver 2012-08-01 3:47 ` Darren Hart 2012-08-01 4:55 ` Khem Raj @ 2012-08-01 6:15 ` Martin Jansa 2012-08-01 16:22 ` Darren Hart 1 sibling, 1 reply; 10+ messages in thread From: Martin Jansa @ 2012-08-01 6:15 UTC (permalink / raw) To: Darren Hart; +Cc: Yocto Project [-- Attachment #1: Type: text/plain, Size: 1678 bytes --] On Tue, Jul 31, 2012 at 08:47:47PM -0700, Darren Hart wrote: > > > On 07/31/2012 08:13 PM, Khem Raj wrote: > > > > On Jul 31, 2012, at 7:46 PM, Darren Hart <dvhart@linux.intel.com> wrote: > > > >> I am trying to debug a userpsace application that misbehaves under > >> poky-tiny. My current approach is use gdbserver on the target and attach > >> to the offending process, then connect to it on the client using the > >> yocto-built native gdb for the target. > >> > >> I can easily add gdbserver to the target image, and can successfully > >> connect it to the process: > >> > >> # From the target (qemux86) root shell: > >> # dropbearkey -t rsa -f ./rsa > >> # dropbear -r ./rsa > >> # DBPID=$(ps | grep dropbear | head -n1 | cut -f4 -d ' ') > >> # gdbserver 127.0.0.1:1234 --attach $DBPID > >> > >> Now on the host machine (amd64) I want to: > >> $ gdb???? > >> (gdb) target extended-remote 127.0.0.1:1234 > >> > >> Which package do I need to build to get the appropriate gdb for the host > >> to remote debug processes on the target? > > > > bake cross-gdb for your arch and use it same way as above > > ERROR: Nothing PROVIDES 'cross-gdb' > > gdb-cross maybe? > > Ah that gets a lot farther... and then do_compile fails. > > | libgdb.a(python.o): In function `gdbpy_target_wide_charset': > | python.c:(.text+0x1c7): undefined reference to `PyUnicodeUCS4_Decode' > > And a lot more similar to that. I'm doing this on poky-tiny (so a > minimal target libc... shouldn't impact native bits though right? http://patchwork.openembedded.org/patch/33345/ Cheers, -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Debug with gdbserver 2012-08-01 6:15 ` Martin Jansa @ 2012-08-01 16:22 ` Darren Hart 2012-08-01 17:09 ` Khem Raj 0 siblings, 1 reply; 10+ messages in thread From: Darren Hart @ 2012-08-01 16:22 UTC (permalink / raw) To: Martin Jansa; +Cc: Yocto Project -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/31/2012 11:15 PM, Martin Jansa wrote: > On Tue, Jul 31, 2012 at 08:47:47PM -0700, Darren Hart wrote: >> >> >> On 07/31/2012 08:13 PM, Khem Raj wrote: >>> >>> On Jul 31, 2012, at 7:46 PM, Darren Hart >>> <dvhart@linux.intel.com> wrote: >>> >>>> I am trying to debug a userpsace application that misbehaves >>>> under poky-tiny. My current approach is use gdbserver on the >>>> target and attach to the offending process, then connect to >>>> it on the client using the yocto-built native gdb for the >>>> target. >>>> >>>> I can easily add gdbserver to the target image, and can >>>> successfully connect it to the process: >>>> >>>> # From the target (qemux86) root shell: # dropbearkey -t rsa >>>> -f ./rsa # dropbear -r ./rsa # DBPID=$(ps | grep dropbear | >>>> head -n1 | cut -f4 -d ' ') # gdbserver 127.0.0.1:1234 >>>> --attach $DBPID >>>> >>>> Now on the host machine (amd64) I want to: $ gdb???? (gdb) >>>> target extended-remote 127.0.0.1:1234 >>>> >>>> Which package do I need to build to get the appropriate gdb >>>> for the host to remote debug processes on the target? >>> >>> bake cross-gdb for your arch and use it same way as above >> >> ERROR: Nothing PROVIDES 'cross-gdb' >> >> gdb-cross maybe? >> >> Ah that gets a lot farther... and then do_compile fails. >> >> | libgdb.a(python.o): In function `gdbpy_target_wide_charset': | >> python.c:(.text+0x1c7): undefined reference to >> `PyUnicodeUCS4_Decode' >> >> And a lot more similar to that. I'm doing this on poky-tiny (so >> a minimal target libc... shouldn't impact native bits though >> right? > > http://patchwork.openembedded.org/patch/33345/ Excellent, that gets things building. Now I'm trying to use it and getting a timeout. I'm investigating, but if anyone has run into this already and can save me the time, I'd appreciate it. I start qemu with: $ qemu -kernel /build/poky/master/qemux86_SZ60LW/tmp/deploy/images/bzImage-qemux86.bin - -initrd /build/poky/master/qemux86_SZ60LW/tmp/deploy/images/core-image-minimal-qemux86.cpio.gz - -nographic -append "console=ttyS0 root=/dev/ram0" -redir tcp:1234::1234 Then run the following on the target: # dropbearkey -t rsa -f ./rsa # dropbear -r ./rsa # DBPID=$(ps | grep dropbear | head -n1 | cut -f4 -d ' ') # gdbserver 127.0.0.1:1234 --attach $DBPID ... Attached; pid = 41 Listening on port 1234 Then from the host: $ nmap localhost ... 1234/tcp open hotline .... $ i586-poky-linux-gdb GNU gdb (GDB) 7.4.1 Copyright (C) 2012 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-linux --target=i586-poky-linux". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. (gdb) target extended-remote 127.0.0.1:1234 Remote debugging using 127.0.0.1:1234 Ignoring packet error, continuing... warning: unrecognized item "timeout" in "qSupported" response Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Remote communication error. Target disconnected.: Connection reset by peer. - -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQGVfEAAoJEKbMaAwKp364Ug8H/0yXaF/jqZdrl3XEnM0mT4Ef gvTIEQ4yAr015Ra2TV9kTUEqb0tnKR1chfZDveEmlBf84ZUsnArFvUseaCMQ1sz6 0lG5iAdeY6Cpo4UKPmpxgLCCMo3nEUIULvA4XrsTakvEgUH4DhssmgEOTOi/aaQ3 Fc9YtpUvXjC63eyRNqYk5sEMWzEVMSxbRHUegllGrsK+eeacEYoA1/TFFiK0c6lH cLL/mZsnbzPFh9a1SteR1D9YC7tmrooGyaWBz/zZ8UYNfTlP5JfsQA/GZHc6wmWn h6Ml9l9DdnNQxXX8Ff6nyEYgc1714u8OEl/Wno6wwJdCh9U9OvxfRC5KxMKkMWg= =yC5/ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Debug with gdbserver 2012-08-01 16:22 ` Darren Hart @ 2012-08-01 17:09 ` Khem Raj 2012-08-01 17:16 ` Darren Hart 0 siblings, 1 reply; 10+ messages in thread From: Khem Raj @ 2012-08-01 17:09 UTC (permalink / raw) To: Darren Hart; +Cc: Yocto Project On Wed, Aug 1, 2012 at 9:22 AM, Darren Hart <dvhart@linux.intel.com> wrote: > (gdb) target extended-remote 127.0.0.1:1234 this should be ip of target which in your case is qemu prolly something like 192.168.7.2 or somesuch ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Debug with gdbserver 2012-08-01 17:09 ` Khem Raj @ 2012-08-01 17:16 ` Darren Hart 2012-08-01 22:34 ` Khem Raj 0 siblings, 1 reply; 10+ messages in thread From: Darren Hart @ 2012-08-01 17:16 UTC (permalink / raw) To: Khem Raj; +Cc: Yocto Project On 08/01/2012 10:09 AM, Khem Raj wrote: > On Wed, Aug 1, 2012 at 9:22 AM, Darren Hart <dvhart@linux.intel.com> wrote: >> (gdb) target extended-remote 127.0.0.1:1234 > > this should be ip of target which in your case is qemu prolly > something like 192.168.7.2 or somesuch > I was trying to use the "redir" feature of qemu which supposedly allows you to connect to 1234 on the host instead. After looking at this for a bit and not making any progress, I setup tun/tap networking with qemu and easily connected using the target IP as you mention above. I'd like to understand why redir didn't work - as debugging without a full network on the client would be nice - but for now, I'm moving along. Thanks, -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Debug with gdbserver 2012-08-01 17:16 ` Darren Hart @ 2012-08-01 22:34 ` Khem Raj 2012-08-01 22:35 ` Darren Hart 0 siblings, 1 reply; 10+ messages in thread From: Khem Raj @ 2012-08-01 22:34 UTC (permalink / raw) To: Darren Hart; +Cc: Yocto Project On Aug 1, 2012, at 10:16 AM, Darren Hart <dvhart@linux.intel.com> wrote: > > > On 08/01/2012 10:09 AM, Khem Raj wrote: >> On Wed, Aug 1, 2012 at 9:22 AM, Darren Hart <dvhart@linux.intel.com> wrote: >>> (gdb) target extended-remote 127.0.0.1:1234 >> >> this should be ip of target which in your case is qemu prolly >> something like 192.168.7.2 or somesuch >> > > I was trying to use the "redir" feature of qemu which supposedly allows > you to connect to 1234 on the host instead. After looking at this for a > bit and not making any progress, I setup tun/tap networking with qemu > and easily connected using the target IP as you mention above. I'd like > to understand why redir didn't work - as debugging without a full > network on the client would be nice - but for now, I'm moving along. > well redir is visible to qemu gdb stub not to the software stack that qemu is running in your case. although you can use that to debug kernel using qemu. Pass -s option and qemu will boot kernel using gdb stub and you can debug the kernel from address 0 kind of JTAG debugger for poor :) > Thanks, > > > -- > Darren Hart > Intel Open Source Technology Center > Yocto Project - Technical Lead - Linux Kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Debug with gdbserver 2012-08-01 22:34 ` Khem Raj @ 2012-08-01 22:35 ` Darren Hart 0 siblings, 0 replies; 10+ messages in thread From: Darren Hart @ 2012-08-01 22:35 UTC (permalink / raw) To: Khem Raj; +Cc: Yocto Project On 08/01/2012 03:34 PM, Khem Raj wrote: > > On Aug 1, 2012, at 10:16 AM, Darren Hart <dvhart@linux.intel.com> wrote: > >> >> >> On 08/01/2012 10:09 AM, Khem Raj wrote: >>> On Wed, Aug 1, 2012 at 9:22 AM, Darren Hart <dvhart@linux.intel.com> wrote: >>>> (gdb) target extended-remote 127.0.0.1:1234 >>> >>> this should be ip of target which in your case is qemu prolly >>> something like 192.168.7.2 or somesuch >>> >> >> I was trying to use the "redir" feature of qemu which supposedly allows >> you to connect to 1234 on the host instead. After looking at this for a >> bit and not making any progress, I setup tun/tap networking with qemu >> and easily connected using the target IP as you mention above. I'd like >> to understand why redir didn't work - as debugging without a full >> network on the client would be nice - but for now, I'm moving along. >> > > well redir is visible to qemu gdb stub not to the software stack that qemu is running > in your case. although you can use that to debug kernel using qemu. Pass -s option > and qemu will boot kernel using gdb stub and you can debug the kernel from address 0 > kind of JTAG debugger for poor :) Oh. Duh. :-) -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-08-01 22:37 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-08-01 2:46 Debug with gdbserver Darren Hart 2012-08-01 3:13 ` Khem Raj 2012-08-01 3:47 ` Darren Hart 2012-08-01 4:55 ` Khem Raj 2012-08-01 6:15 ` Martin Jansa 2012-08-01 16:22 ` Darren Hart 2012-08-01 17:09 ` Khem Raj 2012-08-01 17:16 ` Darren Hart 2012-08-01 22:34 ` Khem Raj 2012-08-01 22:35 ` Darren Hart
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.