Can I debug busybox program running on a qemu virtual machine using gdb?
Hi all, I'm trying to track how tftp program runs when I run tftp provided by busybox on qemu virtual machine. I can debug the linux source but I cannot debug tftp (busybox) program. Can I debug busybox program using gdb in this case? Any hint or advice will be very appreciated. Thank you! Chan Kim
Hi, If the goal is only to understand tftp and it's not something hardware dependend I would debug it on my normal desktop system/notebook. My distro (debian) has a busybox package. It does not provide the symlinks to change the ARGV[0] but you can create them manually and then debug locally as usually with your prefered tool (emacs recommended :) ). If it has to be in quemu, I see no reason against it, the normal rules for remote debugging apply. -- Richard Sailer On 07/07/2022 11:27, Chan Kim wrote:
Hi all,
I'm trying to track how tftp program runs when I run tftp provided by busybox on qemu virtual machine. I can debug the linux source but I cannot debug tftp (busybox) program. Can I debug busybox program using gdb in this case? Any hint or advice will be very appreciated. Thank you!
Chan Kim
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi, Thanks for replying. Actually, I just wanted to know what kernel config variables are needed to make tftp work in vanilla linux. I get the message "tftp: sendto: Network is unreachable". With another default config, I can use tftp on qemu machine but still the kernel image size is big so I tried to reduce the size and reduce the experiment cycle time. But now I know I can build my test platform driver into a kernel module I can do away with it. Maybe I'll just try this "finding minimal config for tftp " later. (I though because the shell itself is the busybox, maybe I could find where the program is loaded and set breakpoint in the tftp entrance or condition, but couldn't find where busybox was loaded.) Thank you. Chan Kim
-----Original Message----- From: Richard <richard_siegfried@systemli.org> Sent: Friday, July 8, 2022 8:46 AM To: kernelnewbies@kernelnewbies.org Subject: Re: Can I debug busybox program running on a qemu virtual machine using gdb?
Hi,
If the goal is only to understand tftp and it's not something hardware dependend I would debug it on my normal desktop system/notebook. My distro (debian) has a busybox package. It does not provide the symlinks to change the ARGV[0] but you can create them manually and then debug locally as usually with your prefered tool (emacs recommended :) ).
If it has to be in quemu, I see no reason against it, the normal rules for remote debugging apply.
-- Richard Sailer
On 07/07/2022 11:27, Chan Kim wrote:
Hi all,
I'm trying to track how tftp program runs when I run tftp provided by busybox on qemu virtual machine. I can debug the linux source but I cannot debug tftp (busybox) program. Can I debug busybox program using gdb in this case? Any hint or advice will be very appreciated. Thank you!
Chan Kim
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Fri, 08 Jul 2022 10:11:53 +0900, "Chan Kim" said:
I get the message "tftp: sendto: Network is unreachable".
Unless you did something *really* drastic, like figure out how to build the kernel without IPv4 support (is that even possible yet?), or leave out support for whatever virtual network device qemu is providing to the emulated kernel, you're probably just missing an 'ifconfig' and/or a 'route add' to tell the kernel where the bits need to go. Less likely, you did something silly like tell the kernel to enforce SELinux or AppArmor or whatever, but you fed it a policy file that doesn't allow tftp to have network access....
On Thu, Jul 7, 2022 at 2:27 AM Chan Kim <ckim@etri.re.kr> wrote:
Hi all,
I'm trying to track how tftp program runs when I run tftp provided by busybox on qemu virtual machine. I can debug the linux source but I cannot debug tftp (busybox) program. Can I debug busybox program using gdb in this case? Any hint or advice will be very appreciated. Thank you!
Check the tftp options for verbose flags. The granularity of gdb is finer than most connection problems. tftp in busybox may be a subset of stand alone tftp. fire it up and see what "help" and other commands tell you. As always tftp has two parts. Near and far. Both the server and the client have verbos the server may log authentication or other errors. It would help to run standalone tftp on a laptop and also install busybox in a scratch location to see if there are differences you care about. As a security risk tftp is full of troubles so firewalls and switches can drop traffic. gdb is too fine. If you are building it add classic print statements to the verbose mode. Two programs, two firewalls, is the network local or wild west big with multiple hops and firewalls.
On 08/07/2022 10:36, Tom Mitchell wrote:
On Thu, Jul 7, 2022 at 2:27 AM Chan Kim <ckim@etri.re.kr> wrote:
Hi all,
I'm trying to track how tftp program runs when I run tftp provided by busybox on qemu virtual machine. I can debug the linux source but I cannot debug tftp (busybox) program. Can I debug busybox program using gdb in this case? Any hint or advice will be very appreciated. Thank you!
Check the tftp options for verbose flags. The granularity of gdb is finer than most connection problems.
tftp in busybox may be a subset of stand alone tftp. fire it up and see what "help" and other commands tell you.
As always tftp has two parts. Near and far. Both the server and the client have verbos the server may log authentication or other errors.
It would help to run standalone tftp on a laptop and also install busybox in a scratch location to see if there are differences you care about. As a security risk tftp is full of troubles so firewalls and switches can drop traffic. gdb is too fine. If you are building it add classic print statements to the verbose mode. Two programs, two firewalls, is the network local or wild west big with multiple hops and firewalls.
I agree, that's all pretty good advice
participants (4)
-
Chan Kim -
Richard -
Tom Mitchell -
Valdis Klētnieks