Remote Debugging

Remote Debugging

[Andrew R. Baker]

Could someone who has succesfully set up remote kernel debugging help me
to get it working over here?  This is what I get from gdb when trying to
set up the connection:

(gdb) target remote /dev/ttyS1
Remote debugging using /dev/ttyS1
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Couldn't establish connection to remote target
Malformed response to offset query, timeout


Any suggestions?

-Andrew

Remote Debugging

[Joerg Eesmann]

Hi there,
I am trying to remote debug my Openmoko freerunner.
I already installed succesfully gdbserver, and can attach it to the
progem I am going to debug.
The question is, what to do on host side?
I bitbaked gdb-cross-sdk, I bitbaked my changed package (bluez4)
So I will install a debug version of the package, and attach to the
bluetoothd-demon.
On host side, I guessed I needed a gdb, that can handle ARM-processor,
therefore gdb-cross-sdk.
Now I should have everything... but a few questions left.
GDB ist only ipk-package, what to do with this?
Where do I find the arm-compiler bluetoothd on my host (I guess in work,
but will this be the strippded version or not, because also stripped
package has been made).
Am I on the right way? Is there any howto or something like that
availlable, where you could point me?

thank you for your help in advance,
best regards,
Joerg

Re: Remote Debugging

[Khem Raj]

On (08/01/10 22:37), Joerg Eesmann wrote:
> Hi there,
> I am trying to remote debug my Openmoko freerunner.
> I already installed succesfully gdbserver, and can attach it to the
> progem I am going to debug.
> The question is, what to do on host side?
> I bitbaked gdb-cross-sdk, I bitbaked my changed package (bluez4)
> So I will install a debug version of the package, and attach to the
> bluetoothd-demon.
> On host side, I guessed I needed a gdb, that can handle ARM-processor,
> therefore gdb-cross-sdk.
> Now I should have everything... but a few questions left.
> GDB ist only ipk-package, what to do with this?

you need gdb-cross once you build that you should be able to use it
from same place as cross gcc.

> Where do I find the arm-compiler bluetoothd on my host (I guess in work,
> but will this be the strippded version or not, because also stripped
> package has been made).
> Am I on the right way? Is there any howto or something like that
> availlable, where you could point me?
> 

if you build it then the non stripped version should be there in 
your workdir (where the package was built)

-Khem
> thank you for your help in advance,
> best regards,
> Joerg
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Remote Debugging

[Joerg Eesmann]

Hi again,
sometimes one can`t see the obvious, but thanks for help.
I connected gdb remote. But I got following message:

warning: The current binary is a PIE (Position Independent Executable),
which
GDB does NOT currently support.  Most debugger features will fail if
used
in this session.

Reading symbols
from /home/joerg/prj/OpenMoko/shr/shr-build/shr-unstable/tmp/work/armv4t-oe-linux-gnueabi/bluez4-4.59-r5.0/bluez-4.59/src/.libs/bluetoothd...done.
(gdb) target remote 192.168.0.202:3333
Remote debugging using 192.168.0.202:3333
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.

and I cannot set breakpoints or whatever.
I thought, gdb 7.0 is supporting PIE.
Is there any possibility to compile bluez4 not as PIE, would it work?
While googeling, I found some patches for gdb, which may help.
Any ideas?

(by the way, is there a usable graphical frontend for gdb for this case:
remote-debugging wit cross gdb)?
I only managed to get it running (until the message) textbased.

Thank you for supporting me,
best regards,
Joerg


On Fri, 2010-01-08 at 14:39 -0800, Khem Raj wrote:
> On (08/01/10 22:37), Joerg Eesmann wrote:
> > Hi there,
> > I am trying to remote debug my Openmoko freerunner.
> > I already installed succesfully gdbserver, and can attach it to the
> > progem I am going to debug.
> > The question is, what to do on host side?
> > I bitbaked gdb-cross-sdk, I bitbaked my changed package (bluez4)
> > So I will install a debug version of the package, and attach to the
> > bluetoothd-demon.
> > On host side, I guessed I needed a gdb, that can handle ARM-processor,
> > therefore gdb-cross-sdk.
> > Now I should have everything... but a few questions left.
> > GDB ist only ipk-package, what to do with this?
> 
> you need gdb-cross once you build that you should be able to use it
> from same place as cross gcc.
> 
> > Where do I find the arm-compiler bluetoothd on my host (I guess in work,
> > but will this be the strippded version or not, because also stripped
> > package has been made).
> > Am I on the right way? Is there any howto or something like that
> > availlable, where you could point me?
> > 
> 
> if you build it then the non stripped version should be there in 
> your workdir (where the package was built)
> 
> -Khem
> > thank you for your help in advance,
> > best regards,
> > Joerg
> > 
> > 
> > 
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Remote Debugging

[Khem Raj]

On Sat, Jan 9, 2010 at 9:15 AM, Joerg Eesmann <jeesmann@gmx.de> wrote:
> Hi again,
> sometimes one can`t see the obvious, but thanks for help.
> I connected gdb remote. But I got following message:
>
> warning: The current binary is a PIE (Position Independent Executable),
> which
> GDB does NOT currently support.  Most debugger features will fail if
> used
> in this session.
>
> Reading symbols
> from /home/joerg/prj/OpenMoko/shr/shr-build/shr-unstable/tmp/work/armv4t-oe-linux-gnueabi/bluez4-4.59-r5.0/bluez-4.59/src/.libs/bluetoothd...done.
> (gdb) target remote 192.168.0.202:3333
> Remote debugging using 192.168.0.202:3333
> warning: Unable to find dynamic linker breakpoint function.
> GDB will be unable to debug shared library initializers
> and track explicitly loaded dynamic code.
>
> and I cannot set breakpoints or whatever.
> I thought, gdb 7.0 is supporting PIE.
> Is there any possibility to compile bluez4 not as PIE, would it work?

you could add -nopie to ldflags

> While googeling, I found some patches for gdb, which may help.
> Any ideas?

they could if you send the pointers.

>
> (by the way, is there a usable graphical frontend for gdb for this case:
> remote-debugging wit cross gdb)?

I have used ddd its decent. You can also use eclipse CDT they are others too
http://sourceware.org/gdb/wiki/GDB%20Front%20Ends

> I only managed to get it running (until the message) textbased.
>
> Thank you for supporting me,
> best regards,
> Joerg
>
>
> On Fri, 2010-01-08 at 14:39 -0800, Khem Raj wrote:
>> On (08/01/10 22:37), Joerg Eesmann wrote:
>> > Hi there,
>> > I am trying to remote debug my Openmoko freerunner.
>> > I already installed succesfully gdbserver, and can attach it to the
>> > progem I am going to debug.
>> > The question is, what to do on host side?
>> > I bitbaked gdb-cross-sdk, I bitbaked my changed package (bluez4)
>> > So I will install a debug version of the package, and attach to the
>> > bluetoothd-demon.
>> > On host side, I guessed I needed a gdb, that can handle ARM-processor,
>> > therefore gdb-cross-sdk.
>> > Now I should have everything... but a few questions left.
>> > GDB ist only ipk-package, what to do with this?
>>
>> you need gdb-cross once you build that you should be able to use it
>> from same place as cross gcc.
>>
>> > Where do I find the arm-compiler bluetoothd on my host (I guess in work,
>> > but will this be the strippded version or not, because also stripped
>> > package has been made).
>> > Am I on the right way? Is there any howto or something like that
>> > availlable, where you could point me?
>> >
>>
>> if you build it then the non stripped version should be there in
>> your workdir (where the package was built)
>>
>> -Khem
>> > thank you for your help in advance,
>> > best regards,
>> > Joerg
>> >
>> >
>> >
>> > _______________________________________________
>> > Openembedded-devel mailing list
>> > Openembedded-devel@lists.openembedded.org
>> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Remote Debugging

[FQ | Jaume Ribot]

Khem Raj escribió:
> On Sat, Jan 9, 2010 at 9:15 AM, Joerg Eesmann <jeesmann@gmx.de> wrote:
>   
>> Hi again,
>> sometimes one can`t see the obvious, but thanks for help.
>> I connected gdb remote. But I got following message:
>>
>> warning: The current binary is a PIE (Position Independent Executable),
>> which
>> GDB does NOT currently support.  Most debugger features will fail if
>> used
>> in this session.
>>
>> Reading symbols
>> from /home/joerg/prj/OpenMoko/shr/shr-build/shr-unstable/tmp/work/armv4t-oe-linux-gnueabi/bluez4-4.59-r5.0/bluez-4.59/src/.libs/bluetoothd...done.
>> (gdb) target remote 192.168.0.202:3333
>> Remote debugging using 192.168.0.202:3333
>> warning: Unable to find dynamic linker breakpoint function.
>> GDB will be unable to debug shared library initializers
>> and track explicitly loaded dynamic code.
>>
>> and I cannot set breakpoints or whatever.
>> I thought, gdb 7.0 is supporting PIE.
>> Is there any possibility to compile bluez4 not as PIE, would it work?
>>     
>
> you could add -nopie to ldflags
>
>   
>> While googeling, I found some patches for gdb, which may help.
>> Any ideas?
>>     
>
> they could if you send the pointers.
>
>   
>> (by the way, is there a usable graphical frontend for gdb for this case:
>> remote-debugging wit cross gdb)?
>>     
>
> I have used ddd its decent. You can also use eclipse CDT they are others too
> http://sourceware.org/gdb/wiki/GDB%20Front%20Ends
>   
I also used eclipse (galileo) with CDT extensions. It's a good idea, as
you can compile/debug the application with the same tool.

>   
>> I only managed to get it running (until the message) textbased.
>>
>> Thank you for supporting me,
>> best regards,
>> Joerg
>>
>>
>> On Fri, 2010-01-08 at 14:39 -0800, Khem Raj wrote:
>>     
>>> On (08/01/10 22:37), Joerg Eesmann wrote:
>>>       
>>>> Hi there,
>>>> I am trying to remote debug my Openmoko freerunner.
>>>> I already installed succesfully gdbserver, and can attach it to the
>>>> progem I am going to debug.
>>>> The question is, what to do on host side?
>>>> I bitbaked gdb-cross-sdk, I bitbaked my changed package (bluez4)
>>>> So I will install a debug version of the package, and attach to the
>>>> bluetoothd-demon.
>>>> On host side, I guessed I needed a gdb, that can handle ARM-processor,
>>>> therefore gdb-cross-sdk.
>>>> Now I should have everything... but a few questions left.
>>>> GDB ist only ipk-package, what to do with this?
>>>>         
>>> you need gdb-cross once you build that you should be able to use it
>>> from same place as cross gcc.
>>>
>>>       
>>>> Where do I find the arm-compiler bluetoothd on my host (I guess in work,
>>>> but will this be the strippded version or not, because also stripped
>>>> package has been made).
>>>> Am I on the right way? Is there any howto or something like that
>>>> availlable, where you could point me?
>>>>
>>>>         
>>> if you build it then the non stripped version should be there in
>>> your workdir (where the package was built)
>>>
>>> -Khem
>>>       
>>>> thank you for your help in advance,
>>>> best regards,
>>>> Joerg
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openembedded-devel mailing list
>>>> Openembedded-devel@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>>         
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>       
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>>     
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>   


-- 
Jaume Ribot Caner
R&D Engineer

FQ Ingeniería Electrónica, SA
Avda. de les Roquetes, 9
Pol. Industrial Vilanoveta
08812 Sant Pere de Ribes ( SPAIN )
www.fqingenieria.es

Tf  + 34 93 208 02 58
Fx  + 34 93 459 28 93
E-mail: jaume@fqingenieria.es

Re: Remote Debugging

[Chris Simmonds]

FQ | Jaume Ribot wrote:
>>> (by the way, is there a usable graphical frontend for gdb for this case:
>>> remote-debugging wit cross gdb)?
>>>     
>>
>> I have used ddd its decent. You can also use eclipse CDT they are 
>> others too
>> http://sourceware.org/gdb/wiki/GDB%20Front%20Ends
>>   
> I also used eclipse (galileo) with CDT extensions. It's a good idea, as
> you can compile/debug the application with the same tool.
> 

FYI: there is an article on using Eclipse for remote debug (written by 
me) here
http://www.embedded-linux.co.uk/tutorial/eclipse-rse

-- 
Chris Simmonds                   2net Limited
chris@2net.co.uk                 http://www.2net.co.uk/

Re: Remote Debugging

[Joerg Eesmann]

Hi all,
with your help I came to the point, where I could remotely set
breakpoints. I added "--disable-pie" to EXTRA_OECONF.
Now it should work, but the only way, I can set breakpoints is with
function names.
In the executable I find in the workdir of bluez (bluetoothd), I do not
see the filenames. Right now, I am using Codelite as frontend for gdb,
and codelite only can set breakpoints like filename:line (I guess like
every other frontend).
Is there a way to have an executable with all the debug information in?
Or am I wrong here, and I just did not get the right configuration?
(with filename:line I tried only filename, full path, relative path to
Make-Dir, but nothing worked)
thank you for your help,
best regards
Joerg Eesmann


On Sat, 2010-01-09 at 18:15 +0100, Joerg Eesmann wrote:
> Hi again,
> sometimes one can`t see the obvious, but thanks for help.
> I connected gdb remote. But I got following message:
> 
> warning: The current binary is a PIE (Position Independent Executable),
> which
> GDB does NOT currently support.  Most debugger features will fail if
> used
> in this session.
> 
> Reading symbols
> from /home/joerg/prj/OpenMoko/shr/shr-build/shr-unstable/tmp/work/armv4t-oe-linux-gnueabi/bluez4-4.59-r5.0/bluez-4.59/src/.libs/bluetoothd...done.
> (gdb) target remote 192.168.0.202:3333
> Remote debugging using 192.168.0.202:3333
> warning: Unable to find dynamic linker breakpoint function.
> GDB will be unable to debug shared library initializers
> and track explicitly loaded dynamic code.
> 
> and I cannot set breakpoints or whatever.
> I thought, gdb 7.0 is supporting PIE.
> Is there any possibility to compile bluez4 not as PIE, would it work?
> While googeling, I found some patches for gdb, which may help.
> Any ideas?
> 
> (by the way, is there a usable graphical frontend for gdb for this case:
> remote-debugging wit cross gdb)?
> I only managed to get it running (until the message) textbased.
> 
> Thank you for supporting me,
> best regards,
> Joerg
> 
> 
> On Fri, 2010-01-08 at 14:39 -0800, Khem Raj wrote:
> > On (08/01/10 22:37), Joerg Eesmann wrote:
> > > Hi there,
> > > I am trying to remote debug my Openmoko freerunner.
> > > I already installed succesfully gdbserver, and can attach it to the
> > > progem I am going to debug.
> > > The question is, what to do on host side?
> > > I bitbaked gdb-cross-sdk, I bitbaked my changed package (bluez4)
> > > So I will install a debug version of the package, and attach to the
> > > bluetoothd-demon.
> > > On host side, I guessed I needed a gdb, that can handle ARM-processor,
> > > therefore gdb-cross-sdk.
> > > Now I should have everything... but a few questions left.
> > > GDB ist only ipk-package, what to do with this?
> > 
> > you need gdb-cross once you build that you should be able to use it
> > from same place as cross gcc.
> > 
> > > Where do I find the arm-compiler bluetoothd on my host (I guess in work,
> > > but will this be the strippded version or not, because also stripped
> > > package has been made).
> > > Am I on the right way? Is there any howto or something like that
> > > availlable, where you could point me?
> > > 
> > 
> > if you build it then the non stripped version should be there in 
> > your workdir (where the package was built)
> > 
> > -Khem
> > > thank you for your help in advance,
> > > best regards,
> > > Joerg
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > 
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel