Debug with gdbserver

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?

Signature · 7 lines

Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto

Quoted 14 lines · Darren Hart

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

Quoted 6 lines

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

Quoted 21 lines · Khem Raj

Quoted 18 lines · Darren Hart

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

Quoted 4 lines

Quoted 2 lines

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.

Signature · 3 lines

Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Quoted 17 lines · Khem Raj

Quoted 14 lines · Darren Hart

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

Quoted 8 lines

Quoted 6 lines

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?

Quoted 39 lines · Darren Hart

Quoted 18 lines · Khem Raj

Quoted 14 lines · Darren Hart

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

Quoted 7 lines

Quoted 5 lines

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'

Quoted 3 lines

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/

(gdb) target extended-remote 127.0.0.1:1234

Quoted 1 line · Darren Hart

(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

Quoted 6 lines · Khem Raj

Quoted 1 line · Darren Hart

(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,

Signature · 3 lines

Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Quoted 10 lines · Darren Hart

Quoted 6 lines · Khem Raj

Quoted 1 line · Darren Hart

(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

Quoted 7 lines

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