forked from enlightenment/www-content
Wiki pages remote_debugging created
Signed-off-by: Clément Bénier <clement.benier@openwide.fr>
This commit is contained in:
parent
931f4fe10f
commit
bb46cd66f4
Binary file not shown.
After Width: | Height: | Size: 440 KiB |
|
@ -0,0 +1,233 @@
|
|||
~~Title: Remote debugging~~
|
||||
==== Remote Debugging ====
|
||||
|
||||
This tutorial aims at providing approaches to remote debugging.
|
||||
|
||||
- [[|ssh]]
|
||||
- [[|Gdb server]]
|
||||
- [[|clouseau]]
|
||||
|
||||
=== SSH ===
|
||||
|
||||
Remote debugging through ssh was not detailed but approached in
|
||||
[[/debugging/enlightenment_debugging|Enlightenment Debugging]] section. In
|
||||
this section, it is more convenience to use ssh for debugging enlightenment
|
||||
because X is not available.
|
||||
|
||||
The version of SSH that you will want to use on Linux is called OpenSSH.
|
||||
To really make ssh useful, you need a shell account on a remote machine.
|
||||
|
||||
The first thing we'll do is simply connect to a remote machine. This is
|
||||
accomplished by running 'ssh hostname' on your local machine. The hostname
|
||||
that you supply as an argument is the hostname of the remote machine that you
|
||||
want to connect to. By default ssh will assume that you want to authenticate
|
||||
as the same user you use on your local machine. To override this and use a
|
||||
different user, simply use ''remoteusername@remotehostname'' or
|
||||
''remoteusername@remoteipadress'' as the argument.
|
||||
|
||||
On your host machine:
|
||||
<code bash>
|
||||
ssh $remote_user_name@$remote_ip_address
|
||||
#or
|
||||
ssh $remote_user_name@$remote_hostname
|
||||
</code>
|
||||
|
||||
The first time around it will ask you if you wish to add the remote host to a
|
||||
list of known_hosts, go ahead and say yes.
|
||||
|
||||
<code bash>
|
||||
The authenticity of host '10.5.18.65 (10.5.18.65)' can't be established.
|
||||
ECDSA key fingerprint is f0:72:8c:9d:aa:54:e4:5a:39:50:b5:b9:fd:35:71:71.
|
||||
Are you sure you want to continue connecting (yes/no)? yes
|
||||
Warning: Permanently added '10.5.18.65' (ECDSA) to the list of known hosts.
|
||||
</code>
|
||||
|
||||
It is important to pay attention to this question however because this is one
|
||||
of SSH's major features. Host validation. To put it simply, ssh will check to
|
||||
make sure that you are connecting to the host that you think you are
|
||||
connecting to. That way if someone tries to trick you into logging into their
|
||||
machine instead so that they can sniff your SSH session, you will have some
|
||||
warning.
|
||||
|
||||
Finally, your user password should be asked and you can execute your command
|
||||
as you were on the distant machine:
|
||||
[[/debugging/enlightenment_debugging#Debugging_Enlightenment_using_GDB|
|
||||
Debugging Enlightenment using GDB]].
|
||||
|
||||
You can also use ssh-keygen to generate RSA and DSA keys. Public key
|
||||
authentication for SSH sessions are far superior to any password
|
||||
authentication and provide much higher security. ssh-keygen is the basic way
|
||||
for generating keys for such kind of authentication.
|
||||
|
||||
=== Gdbserver ===
|
||||
|
||||
''gdbserver'' is a control program for Unix-like systems, which allows you to
|
||||
connect your program with a remote ''gdb'' via ''target remote'' but without linking
|
||||
in the usual debugging stub.
|
||||
|
||||
''gdbserver'' is not a complete replacement for the debugging stubs, because
|
||||
it requires essentially the same operating-system facilities that ''gdb''
|
||||
itself does. In fact, a system that can run ''gdbserver'' to connect to a
|
||||
remote ''gdb'' could also run ''gdb'' locally! ''gdbserver'' is sometimes
|
||||
useful nevertheless, because it is a much smaller program than ''gdb'' itself.
|
||||
It is also easier to port than all of ''gdb'', so you may be able to get
|
||||
started more quickly on a new system by using ''gdbserver''. Finally, if you
|
||||
develop code for real-time systems, you may find that the tradeoffs involved
|
||||
in real-time operation make it more convenient to do as much development work
|
||||
as possible on another system, for example by cross-compiling. You can use
|
||||
''gdbserver'' to make a similar choice for debugging.
|
||||
|
||||
''gdb'' and ''gdbserver'' communicate via either a serial line or a TCP
|
||||
connection, using the standard gdb remote serial protocol.
|
||||
|
||||
<note>
|
||||
''gdbserver'' does not have any built-in security. Do not run ''gdbserver'' connected
|
||||
to any public network; a ''gdb'' connection to ''gdbserver'' provides access to the
|
||||
target system with the same privileges as the user running ''gdbserver''.
|
||||
</note>
|
||||
|
||||
First, you have to install ''gdbserver'' on your server side.
|
||||
|
||||
Then, use a segfault program, you can use as in [[apps_efl_debugging#Segfault
|
||||
in callback function]].
|
||||
|
||||
run ''gdbserver'':
|
||||
|
||||
<code bash>
|
||||
#server
|
||||
gdbserver localhost:2000 hello
|
||||
</code>
|
||||
<code bash>
|
||||
$ Process hello created; pid = 2763
|
||||
$ Listening on port 2000
|
||||
</code>
|
||||
|
||||
Now ''gdbserver'' is waiting for a connexion on the port 2000.
|
||||
|
||||
<note>
|
||||
You could launch ''gdb'' in multiple process with ''gdbserver --multi
|
||||
localhost:2000''.
|
||||
<\note>
|
||||
|
||||
On the client side, run ''gdb'':
|
||||
|
||||
<code bash>
|
||||
#client
|
||||
gdb hello
|
||||
</code>
|
||||
<code bash>
|
||||
...
|
||||
$ Type "apropos word" to search for commands related to "word"...
|
||||
$ Reading symbols from test...(no debugging symbols found)...done.
|
||||
</code>
|
||||
|
||||
Use ''target remote''e to connect to the target system by indicating server ip
|
||||
and port.
|
||||
|
||||
<code bash>
|
||||
#client
|
||||
(gdb) target remote 10.5.18.65:2000
|
||||
</code>
|
||||
<code bash>
|
||||
$ Remote debugging using 10.5.18.65:2000
|
||||
$ Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from
|
||||
$ /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done.
|
||||
$ done.
|
||||
$ Loaded symbols for /lib64/ld-linux-x86-64.so.2
|
||||
$ 0x00007ffff7ddb2d0 in _start () from /lib64/ld-linux-x86-64.so.2
|
||||
</code>
|
||||
|
||||
At that point, you can add breakpoints or others, then if we continue our
|
||||
program, the output of the program will be printed in the target machine.
|
||||
|
||||
<code bash>
|
||||
#client
|
||||
(gdb) continue
|
||||
</code>
|
||||
|
||||
Now, the application is launched on server: if as i do you use the
|
||||
[[apps_efl_debugging#Segfault in callback function]]
|
||||
example: click on the seg button will provoke a segfault.
|
||||
|
||||
See after clicking, the traces on the client side:
|
||||
|
||||
<code bash>
|
||||
$ Program received signal SIGSEGV, Segmentation fault.
|
||||
$ 0x0000000000400b71 in ?? ()
|
||||
</code>
|
||||
|
||||
You can now use ''gdb'' as it is explaines in [[apps_efl_debugging#Segfault in
|
||||
callback function]], for example print the backtrace:
|
||||
|
||||
<code bash>
|
||||
(gdb) bt
|
||||
</code>
|
||||
<code bash>
|
||||
$ 0 0x0000000000400b71 in ?? ()
|
||||
$ 1 0x000000000073a9a0 in ?? ()
|
||||
$ 2 0x00007ffff74e4f6c in _eo_evas_smart_cb (data=<optimized out>, eo_obj=<optimized out>, desc=<optimized out>, event_info=<optimized out>) at lib/evas/canvas/evas_object_smart.c:65
|
||||
$ 3 0x00007ffff561a8b7 in _eo_base_event_callback_call (obj_id=0x80000007e0000040, pd=0x73a3f0, desc=0x85d4c0, event_info=0x0) at lib/eo/eo_base_class.c:712
|
||||
$ 4 0x00007ffff5619648 in eo_event_callback_call (desc=desc@entry=0x85d4c0, event_info=event_info@entry=0x0) at lib/eo/eo_base.eo.c:94
|
||||
$ 5 0x00007ffff74e6f6e in evas_object_smart_callback_call (eo_obj=eo_obj@entry=0x80000007e0000040, event=event@entry=0x7ffff7af501f <SIG_CLICKED> "clicked", event_info=event_info@entry=0x0) at lib/evas/canvas/evas_object_smart.c:784
|
||||
$ 6 0x00007ffff7995baf in _activate (obj=0x80000007e0000040) at elm_button.c:69
|
||||
$ 7 0x00007ffff7995be5 in _on_clicked_signal (data=<optimized out>, obj=<optimized out>, emission=<optimized out>, source=<optimized out>) at elm_button.c:191
|
||||
$ 8 0x00007ffff58b0507 in edje_match_callback_exec_check_finals (prop=<optimized out>, ed=0xaaaaaaaaaaaaaaab, source=0x7245b0 "elm", sig=0x73af9c "elm,action,click", source_states=<optimized out>, signal_states=<optimized out>, matches=0x73b0c0, ssp=0x7594e0) at lib/edje/edje_match.c:556
|
||||
$ 9 edje_match_callback_exec (ssp=ssp@entry=0x7594e0, matches=0x73b0c0, sig=sig@entry=0x73af9c "elm,action,click", source=source@entry=0x7245b0 "elm", ed=ed@entry=0x73a9a0, prop=prop@entry=0 '\000') at lib/edje/edje_match.c:711
|
||||
$ 10 0x00007ffff58b6a3d in _edje_emit_cb (prop=0 '\000', data=0x0, src=0x7245b0 "elm", sig=0x73af9c "elm,action,click", ed=0x73a9a0) at lib/edje/edje_program.c:1423
|
||||
$ 11 _edje_emit_handle (ed=0x73a9a0, sig=0x73af9c "elm,action,click", src=0x7245b0 "elm", sdata=0x0, prop=0 '\000') at lib/edje/edje_program.c:1376
|
||||
$ 12 0x00007ffff58b13a1 in _edje_message_process (em=0x667830) at lib/edje/edje_message_queue.c:684
|
||||
$ 13 0x00007ffff58b18b3 in _edje_message_queue_process () at lib/edje/edje_message_queue.c:787
|
||||
$ 14 0x00007ffff58b1a14 in _edje_job (data=<optimized out>) at lib/edje/edje_message_queue.c:154
|
||||
$ 15 0x00007ffff7235a32 in _ecore_job_event_handler (data=<optimized out>, type=<optimized out>, ev=<optimized out>) at lib/ecore/ecore_job.c:121
|
||||
$ 16 0x00007ffff7230463 in _ecore_call_handler_cb (event=<optimized out>, type=<optimized out>, data=<optimized out>, func=<optimized out>) at lib/ecore/ecore_private.h:386
|
||||
$ 17 _ecore_event_call () at lib/ecore/ecore_events.c:565
|
||||
$ 18 0x00007ffff7237e05 in _ecore_main_loop_iterate_internal (once_only=once_only@entry=0) at lib/ecore/ecore_main.c:1927
|
||||
$ 19 0x00007ffff7237f14 in ecore_main_loop_begin () at lib/ecore/ecore_main.c:983
|
||||
$ 20 0x00007ffff7a47e59 in elm_run () at elm_main.c:1097
|
||||
</code>
|
||||
|
||||
=== Clouseau ===
|
||||
|
||||
An UI inspection tool for the EFL. This tool lets you inspect UI elements and
|
||||
get a lot of their properties, e.g position, size and weight. Get more
|
||||
information there: [[apps_efl_debugging#Clouseau]]
|
||||
|
||||
Clouseau consists of a client (clouseau_client) and launcher
|
||||
(clouseau_server). This design means we can: Run the application we are
|
||||
debugging on one device and the clouseau_client itself on another. ''It is very
|
||||
similar to gdbserver''.
|
||||
|
||||
Usage of the split client/server approach (different machines/environments/setups):
|
||||
|
||||
== Server side ==
|
||||
|
||||
Get the ip of your server machine, for example do:
|
||||
|
||||
<code bash>
|
||||
ip a
|
||||
#or
|
||||
ifconfig
|
||||
</code>
|
||||
|
||||
Then start, the server side with the ''clouseau_start'' script launching the
|
||||
application:
|
||||
|
||||
<code bash>
|
||||
clouseau_start elementary_test
|
||||
#or
|
||||
clouseau_start ./your_application
|
||||
</code>
|
||||
|
||||
== Client side ==
|
||||
|
||||
Simply do:
|
||||
|
||||
<code bash>
|
||||
clouseau_client $ip_server
|
||||
</code>
|
||||
|
||||
or use the client interface as below:
|
||||
|
||||
{{ :clouseau_remote.png?1200 }}
|
||||
|
||||
And now, clouseau is usable as in [[apps_efl_debugging#Clouseau]].
|
|
@ -36,6 +36,7 @@ Go check the current available version of EFL on each distro/platform:
|
|||
|
||||
* [[debugging/enlightenment_debugging|Enlightenment debugging]]
|
||||
* [[debugging/apps_efl_debugging|EFL application debugging]]
|
||||
* [[debugging/remote_debugging|Remote Debugging]]
|
||||
* [[debugging/report_bugs|Report bugs on Phabricator]]
|
||||
* [[contact/arcanist|Submit patch on Phabricator]]
|
||||
|
||||
|
|
Loading…
Reference in New Issue