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 LD_LIBRARY_PATH #5

Open
SweetVishnya opened this issue Jan 27, 2021 · 3 comments
Open

Using LD_LIBRARY_PATH #5

SweetVishnya opened this issue Jan 27, 2021 · 3 comments

Comments

@SweetVishnya
Copy link
Contributor

Hi!

I am running symqemu on binary requiring LD_LIBRARY_PATH. Will LD_LIBRARY_PATH=lib SYMCC_INPUT_FILE=file x86_64-linux-user/symqemu-x86_64 ./a.out file work?

I am trying with and without LD_LIBRARY_PATH. It works both ways without any error messages. I cannot tell if it is working correctly.

Also, is there a way to turn off optimistic solving?

@SweetVishnya
Copy link
Contributor Author

What timeout do you use for solver?

@sebastianpoeplau
Copy link
Collaborator

Hi @SweetVishnya,

Not sure about the library search path, I haven't modified anything in that regard. So whatever QEMU's user-mode emulation does applies to SymQEMU as well. I believe it respects your lookup path, and maybe it even has a command-line option to specify a custom path just for the target.

The solver timeout is 10 seconds, inherited from QSYM. As for optimistic solving, there's no switch to disable it, but you can comment out the relevant lines of code in QSYM. (SymCC pulls the QSYM code in via a Git submodule and stores it in runtime/qsym_backend/qsym.)

Hope that helps!

@SweetVishnya
Copy link
Contributor Author

SweetVishnya commented Jan 29, 2021

Thank you for the answers, I will continue evaluating symqemu on Monday. One more question. Do u handle symbolic addresses? Do u generate multiple models for symbolic address as in qsym, they kind of try to solve switch branches that way.

P.S. Also, sent you an email.

rmalmain pushed a commit to rmalmain/symqemu that referenced this issue Aug 9, 2024
…coroutine()' failed.

bdrv_activate_all() should not be called from the coroutine context, move
it to the QEMU thread colo_process_incoming_thread() with the bql_lock
protected.

The backtrace is as follows:
 eurecom-s3#4  0x0000561af7948362 in bdrv_graph_rdlock_main_loop () at ../block/graph-lock.c:260
 eurecom-s3#5  0x0000561af7907a68 in graph_lockable_auto_lock_mainloop (x=0x7fd29810be7b) at /patch/to/qemu/include/block/graph-lock.h:259
 eurecom-s3#6  0x0000561af79167d1 in bdrv_activate_all (errp=0x7fd29810bed0) at ../block.c:6906
 eurecom-s3#7  0x0000561af762b4af in colo_incoming_co () at ../migration/colo.c:935
 eurecom-s3#8  0x0000561af7607e57 in process_incoming_migration_co (opaque=0x0) at ../migration/migration.c:793
 eurecom-s3#9  0x0000561af7adbeeb in coroutine_trampoline (i0=-106876144, i1=22042) at ../util/coroutine-ucontext.c:175
 eurecom-s3#10 0x00007fd2a5cf21c0 in  () at /lib64/libc.so.6

Cc: [email protected]
Cc: Fabiano Rosas <[email protected]>
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2277
Fixes: 2b3912f ("block: Mark bdrv_first_blk() and bdrv_is_root_node() GRAPH_RDLOCK")
Signed-off-by: Li Zhijian <[email protected]>
Reviewed-by: Zhang Chen <[email protected]>
Tested-by: Zhang Chen <[email protected]>
Reviewed-by: Fabiano Rosas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Peter Xu <[email protected]>
(cherry picked from commit 2cc637f)
Signed-off-by: Michael Tokarev <[email protected]>
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