2010/4/29 Peter Soetens <peter [..] ...>

> On Wed, Apr 28, 2010 at 17:52, Philippe Hamelin <
> philippe [dot] hamelin [..] ...> wrote:
>
>> 2010/4/28 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>>
>>>
>>>
>>> 2010/4/28 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>>>
>>>>
>>>> 2010/4/28 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>>>>
>>>>
>>>>>
>>>>> 2010/4/28 Peter Soetens <peter [..] ...>
>>>>>
>>>>> On Tue, Apr 27, 2010 at 20:37, Philippe Hamelin
>>>>>> <philippe [dot] hamelin [..] ...> wrote:
>>>>>> >
>>>>>> >
>>>>>> > 2010/4/27 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>>>>>> >>
>>>>>> >> 2010/4/27 Peter Soetens <peter [..] ...>
>>>>>> >>>
>>>>>> >>> On Tue, Apr 27, 2010 at 15:18, Philippe Hamelin
>>>>>> >>> <philippe [dot] hamelin [..] ...> wrote:
>>>>>> >>> > Hello,
>>>>>> >>> > does someone has been able to remote debug deployed applications
>>>>>> using
>>>>>> >>> > Eclipse? I've been able to try some options (remote GDB-DSF and
>>>>>> manual
>>>>>> >>> > gdbserver + GDB-DSF) using the Debugging Service Framework (DSF)
>>>>>> with
>>>>>> >>> > an
>>>>>> >>> > hello world application. Also, I've been able to debug locally
>>>>>> deployed
>>>>>> >>> > applications using GDB-DSF. However, I'm still not able to find
>>>>>> a fully
>>>>>> >>> > working recipe for remote debugging of deployed applications.
>>>>>> Here is
>>>>>> >>> > my
>>>>>> >>> > setup:
>>>>>> >>> >
>>>>>> >>> > - Eclipse Galileo with GSF 2.0
>>>>>> >>> > - Local folder (/opt/devroot/workspace/MyProject/) mapped by NFS
>>>>>> with
>>>>>> >>> > remote
>>>>>> >>> > folder (/opt/devroot/workspace/MyProject/)
>>>>>> >>> > - deployer-gnulinux NOT compiled in debug mode
>>>>>> >>> > - all my components compiled in debug mode
>>>>>> >>> >
>>>>>> >>> > The simplest recipe that should work is:
>>>>>> >>> >
>>>>>> >>> > 1. Manually start gdbserver on the target
>>>>>> >>> >
>>>>>> >>> > gdbserver --debug :10000 /usr/local/bin/deployer-gnulinux -s
>>>>>> >>> > ./deployment/deployVirtual.xml
>>>>>> >>> >
>>>>>> >>> > 2. Use GDB (GSF) Remote System Process Launcher with the
>>>>>> following
>>>>>> >>> > settings:
>>>>>> >>> >
>>>>>> >>> > * C/C++ Application : /usr/local/bin/deployer-gnulinux
>>>>>> >>> > * Debugger : gdbserver Debugger (the only available choice when
>>>>>> >>> > selecting
>>>>>> >>> > the GSF remote launcher)
>>>>>> >>> > * Connection : TCP
>>>>>> >>> > * Allocate Console : NO (the target console where gdbserver has
>>>>>> been
>>>>>> >>> > started
>>>>>> >>> > is used for in/out)
>>>>>> >>> >
>>>>>> >>> > Then, when I start debug in Eclipse, the connection is
>>>>>> succesfully done
>>>>>> >>> > and
>>>>>> >>> > I'm able to interact with the taskbrowser on the target console.
>>>>>> >>> > However,
>>>>>> >>> > the breakpoints are never reached and I'm not able to see the
>>>>>> threads
>>>>>> >>> > running.
>>>>>> >>>
>>>>>> >>> That's strange. Breakpoints not being reached is an issue when the
>>>>>> >>> debugger can not link the symbols/line numbers to the loaded
>>>>>> libraries
>>>>>> >>> (ie the imported libraries in the deployer). I've had this before
>>>>>> too.
>>>>>> >>> I need to sit in front of my Eclipse installation to oversee which
>>>>>> >>> settings are necessary to get it to load the symbols of the loaded
>>>>>> >>> libraries (it's not doing that automatically). I'm not at my
>>>>>> station
>>>>>> >>> before thursday.
>>>>>> >>> However I could always see the threads running, since gdb knows
>>>>>> >>> threads are created. So this indicates something more fundamental
>>>>>> is
>>>>>> >>> wrong with your setup than just missing symbols.
>>>>>> >>>
>>>>>> >>> I have had mixed results with DSF vs 'old' remote process
>>>>>> >>> debugger/launcher plugins (there are 3 ways to debug a remote
>>>>>> >>> application in Eclipse Galileo). I use DSF by default, but with
>>>>>> >>> unresponsive targets, I revert back to non-DSF. I consider DSF
>>>>>> less
>>>>>> >>> stable than traditional GDB integration.
>>>>>> >>>
>>>>>> >>
>>>>>> >> I also tried the non-DSF with poor results.
>>>>>> >>
>>>>>> >>>
>>>>>> >>> Finally, GDB7 is less stable than GDB6.8, so try to use 6.8 if
>>>>>> possible.
>>>>>> >>>
>>>>>> >>
>>>>>> >> I'm using gdb 6.8 (debian lenny).
>>>>>> >>
>>>>>> >>>
>>>>>> >>> >
>>>>>> >>> > The fact that the deployer hasn't been compiled in debug mode
>>>>>> didn't
>>>>>> >>> > affected the local debugging. However, could this have something
>>>>>> to do
>>>>>> >>> > in
>>>>>> >>> > remote debugging?
>>>>>> >>>
>>>>>> >>> AFAIK, you should have exactly the same features remote and local,
>>>>>> so
>>>>>> >>> it's a setup thing.
>>>>>> >>>
>>>>>> >>
>>>>>> >> I tried with the deployer compiled in debug mode and I have the
>>>>>> same
>>>>>> >> issues.
>>>>>> >>
>>>>>> >> This is my Eclipse project to test these issues. If you can test it
>>>>>> on
>>>>>> >> your side it would be very helpful.
>>>>>> >>
>>>>>> >> Philippe
>>>>>> >>
>>>>>> >
>>>>>> > I did some more tests and the setup works fine with gdbserver
>>>>>> running on the
>>>>>> > host. However, this doesn't work when gdbserver is started on the
>>>>>> target
>>>>>> > even if it's the same setup (debian lenny + same shared libs).
>>>>>> >
>>>>>> > This is driving me crazy!
>>>>>>
>>>>>> This *is* crazy. One option I would try out is to download Helios M6,
>>>>>> wich is fairly stable, and try it with that Eclipse version. Warning:
>>>>>> backup your workspace .metadata, because Helios will modify that in a
>>>>>> non-backwards compatible way. project data (.project & .cproject) may
>>>>>> remain in place.
>>>>>>
>>>>>>
>>>>> I will try this out.
>>>>>
>>>>>
>>>>>> Another way to rule out a bug in eclipse is to connect from a running
>>>>>> 'gdbtui deployer-gnulinux' to the server (type 'target robot:10000' in
>>>>>> gdbtui console to connect).
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>
>>>>> I don't know 'gdbtui'. I will try to find some informations about that.
>>>>>
>>>>> Also, I did more tests and I found that the gdb/gdbserver setup works
>>>>> fine when then are running both on the host machine. It's strange since the
>>>>> target computer has the same setup (Debian Lenny i386 with shared libs on
>>>>> the same paths), so it should not make any differences where gdbserver has
>>>>> been started.
>>>>>
>>>>> Philippe
>>>>>
>>>>>
>>>> One more information about this topic. My host is a virtual machine
>>>> running Debian Lenny i386 on an Intel Xeon E5504 and the target is a Celeron
>>>> M. I cloned the virtual machine and now it works fine between the two VMs
>>>> (running on the same CPU). The only setup that is not working is when the
>>>> gdbserver is running on the host computer which has a different
>>>> architecture.
>>>>
>>>>
>>> I found a (non ideal) working setup for gdb/gdbserver.
>>>
>>> Actually, the binary is compiled on the host machine and then "copied"
>>> (nfs share) on the host machine. Since they have the same gcc version and
>>> the same shared libs this works fine. However, I can't make gdb works on the
>>> host with gdbserver running on the target. I found that compiling the binary
>>> (the RTT component shared lib) directly on the target machine make it works.
>>> Also, altough this is not the setup I'm looking for, I found that running
>>> gdbserver on the host machine with gdb on the target also work fine on both
>>> cases. The only difference (I think) from both setup is the kernel version.
>>> It needs more investigations about shared libs dependancies...
>>>
>>>
>> I FINALLY found the source of the problem (but actually not the solution).
>> The kernel of the host computer was recompiled with rt-preempt and that
>> seems to cause the problem. I rebooted with the default debian lenny 2.6.26
>> kernel and now it works fine. Now good luck to find why this strange
>> behavior appears...
>>
>
> Of the Host computer running in the virtual machine or the host of the
> virtual machine ? I clearly don't understand the gdb architecture that the
> client's kernel can influence the threading behavior of the target's
> gdbserver. The only thing I can imagine is that we're looking at a VM bug...
>
>
The host computer running in the virtual machine.

On both computers, the components are compiled with "-rt" flag but only the
target computer has a kernel compiled with rt-preempt. This may cause
confusions in gdb when debugging multi-thread applications compiled with
"-rt" flag on a computer with a non-rt-preempt kernel ?