Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using already running qemu #30

Closed
phros opened this issue Apr 12, 2019 · 3 comments
Closed

Using already running qemu #30

phros opened this issue Apr 12, 2019 · 3 comments

Comments

@phros
Copy link

phros commented Apr 12, 2019

Hi Guys,

I try to learn avatar2 in order to analyse IoT software.
My setup, which I set up manually:

  • ARM qemu running Raspbian
  • chroot inside the qemu with all required files from IoT device
  • webserver-binary running
  • gdbserver attached to running webserver

I managed to connect to the gdbserver with avatar2, but I wonder how this is the correct way to go.
Is it possible to create a QemuTarget for the already running Qemu process?
Or shall I do something completely different?

Every kind of advice or feedback is welcome :)

Cheers

@mariusmue
Copy link
Member

Hi there!
For now, QemuTarget would be responsible for spawning the QemuInstance.

If you want to attach to another Qemu instance, you could advice Qemu to spawn a GDBServer as well, and attach to it using the GDBTarget! Just add:
-gdb tcp::127.0.0.1:[PORT] to your command line arguments for Qemu. Additionally, if you want to halt the CPU on startup, add also the -S flag. Note that this way, you won't be able to access features of avatar-qemu like remote memory.

If you need access to Qemus QMP, you could set the Monitor protocol of your GDBTarget to qmp.

This may work like this (assuming the port for qmp is 9999):

qmp = QMPProtocol(9999, origin=self) 
gdbtargetInstance.protocols.monitor= qmp
qmp.connect()

This would require your Qemu instance started with the qmp server:
-qmp tcp:127.0.0.1:9999,server,nowait

Note that this is not tested and just written from my memory - normally we use the QemuTarget to drive QEMU, and we haven't implemented a RemoteQemuTarget yet - but this could be totally done the way described above. :)

@phros
Copy link
Author

phros commented Apr 12, 2019

Thanks for the feedback, I will give it a try!

@mariusmue
Copy link
Member

As there where no further comments, I'm closing the issue for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants