gdb/gdbserver vs. eclipse

gdb/gdbserver vs. eclipse

[Robert Berger]

Hi,

I managed to step form HelloWorld into the C library and friends with a
.gdbinit file like this:

# don't use default libs from x86/Ubuntu:
set sysroot /opt/adt-target-sysroot/beagle-bone-black-ml
set solib-absolute-prefix /opt/adt-target-sysroot/beagle-bone-black-ml
set solib-search-path  /opt/adt-target-sysroot/beagle-bone-black-ml
# point to the libraries with debug info:
set debug-file-directory
/opt/adt-target-sysroot/beagle-bone-black-ml/usr/lib/debug
# point to the source code:
set substitute-path /usr/src/debug
/opt/adt-target-sysroot/beagle-bone-black-ml/usr/src/debug
set substitute-path /
/opt/adt-target-sysroot/beagle-bone-black-ml/usr/src/debug
# connect to target:
target remote 192.168.42.11:5555
# set some breakpoints:
b main
b 32

When I try to do the same thing with Eclipse luna and the Eclipse plugin
it can not find the sources.

I am able to debug a hello world program with Eclipse, but when I step
into the C library I only see assembly code.

What magic is Eclipse doing?

Shouldn't .gdbinit work as well with Eclipse?

Regards,

Robert..."Software development is like making a baby... You can't make a
baby in one month by impregnating nine women."

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

Re: gdb/gdbserver vs. eclipse

[Rudolf J Streif]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

Hi Robert,

I am seeing the same thing. I cannot even step into a library function unless 
I check "Load shared library symbols automatically" in Debug Configurations > 
Remote C/C++ Application > <Your Application> > Debugger > Shared Libraries.

I also have to add the whole sysroot and solib shebang to the .gdbinit file 
otherwise it won't work.

The sysroot setting from the Yocto Project plugin does not seem to get applied 
to gdb. For some reason adding the path to the sysroot to "Shared Libraries" 
does not work for me either. Although it's the same path I am using in the 
.gdbinit file gdb complains about an architecture mismatch:

warning: `/lib/libc.so.6': Shared library architecture i386 is not compatible 
with target architecture i386:x86-64.
warning: .dynamic section for "/lib/libc.so.6" is not at the expected address 
(wrong library or version mismatch?)

Cheers,
Rudi

[-- Attachment #2: dbgconf.png --]
[-- Type: image/png, Size: 132770 bytes --]

Re: gdb/gdbserver vs. eclipse

[Robert Berger]

[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]

Hi,

On 09/05/2015 02:47 AM, Rudolf J Streif wrote:
> Hi Robert,
> 
> I am seeing the same thing. I cannot even step into a library function unless 
> I check "Load shared library symbols automatically" in Debug Configurations > 
> Remote C/C++ Application > <Your Application> > Debugger > Shared Libraries.

This needs to be turned on.

I think I made some progress - see attached image.

As you can see I stepped into printf and friends.

For this to work I needed a few more things:

1) directory needs the be the same on host and target

the executable on the host:

/home/student/BBBworkspace/HelloBBBAutotooled/src/HelloBBBAutotooled

the executable on the target:

/home/student/BBBWorkspace/HelloBBBAutotooled/src/HelloBBBAutotooled

2) .gdbinit

I copied my gdbinit on the host to

/home/student/BBBworkspace/HelloBBBAutotooled/.gdbinit

that's the .gdbinit

# don't use default libs from x86/Ubuntu:
set sysroot /opt/adt-target-sysroot/beagle-bone-black-ml
set solib-absolute-prefix /opt/adt-target-sysroot/beagle-bone-black-ml
set solib-search-path  /opt/adt-target-sysroot/beagle-bone-black-ml
# point to the libraries with debug info:
set debug-file-directory
/opt/adt-target-sysroot/beagle-bone-black-ml/usr/lib/debug
# point to the source code:
set substitute-path /usr/src/debug
/opt/adt-target-sysroot/beagle-bone-black-ml/usr/src/debug
set substitute-path /
/opt/adt-target-sysroot/beagle-bone-black-ml/usr/src/debug

3) Once you enter the debug view you need to go to the gdb console and:

source /home/student/BBBworkspace/HelloBBBAutotooled/.gdbinit

This did the trick for me.

Regards,

Robert
...The most likely way for the world to be destroyed, most experts
agree, is by accident. That's where we come in; we're computer
professionals. We cause accidents.

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1


[-- Attachment #2: eclipse-debug-system-libs.png --]
[-- Type: image/png, Size: 183960 bytes --]

Re: gdb/gdbserver vs. eclipse

[Rudolf J Streif]

> 
> I think I made some progress - see attached image.

Good.

> 
> As you can see I stepped into printf and friends.
> 
> For this to work I needed a few more things:
> 
> 1) directory needs the be the same on host and target
> 
> the executable on the host:
> 
> /home/student/BBBworkspace/HelloBBBAutotooled/src/HelloBBBAutotooled
> 
> the executable on the target:
> 
> /home/student/BBBWorkspace/HelloBBBAutotooled/src/HelloBBBAutotooled
> 
I do not have to do that. As a matter of fact the executable on my target is 
copied to /usr/bin from the Eclipse workspace. See "Remote Absolute File Path" 
in the Debug Configuration.


> 2) .gdbinit
> 
> I copied my gdbinit on the host to
> 
> /home/student/BBBworkspace/HelloBBBAutotooled/.gdbinit
> 

Yes, that's where Eclipse's Debug Configuration expects it if you do not change 
the setting of "GDB Command File" in the Main subtab of the Debugger tab in 
the Debug configuration.

> that's the .gdbinit
> 
> # don't use default libs from x86/Ubuntu:
> set sysroot /opt/adt-target-sysroot/beagle-bone-black-ml
> set solib-absolute-prefix /opt/adt-target-sysroot/beagle-bone-black-ml
> set solib-search-path  /opt/adt-target-sysroot/beagle-bone-black-ml
> # point to the libraries with debug info:
> set debug-file-directory
> /opt/adt-target-sysroot/beagle-bone-black-ml/usr/lib/debug
> # point to the source code:
> set substitute-path /usr/src/debug
> /opt/adt-target-sysroot/beagle-bone-black-ml/usr/src/debug
> set substitute-path /
> /opt/adt-target-sysroot/beagle-bone-black-ml/usr/src/debug
> 

Yes, looks like mine except that my target is a MinnowBoard Max and I 
installed my SDK in a different location.


> 3) Once you enter the debug view you need to go to the gdb console and:
> 
> source /home/student/BBBworkspace/HelloBBBAutotooled/.gdbinit
> 

Strange. I don't have to do that if GDB command file is set to the path in the 
workspace. I would expect that Eclipse passes the .gdbinit from the workspace 
explicitly to GDB. However, I do have

add-auto-load-safe-path .

in my global .gdbinit (~/.gdbinit).

Cheers,
Rudi

Re: gdb/gdbserver vs. eclipse

[Robert Berger]

Hi,

On 09/05/2015 07:17 PM, Rudolf J Streif wrote:>>
> I do not have to do that. As a matter of fact the executable on my
target is
> copied to /usr/bin from the Eclipse workspace. See "Remote Absolute
File Path"
> in the Debug Configuration.

You are right. I erased the other folder on my target, moved it there as
well and it still works.

>
>
>> 2) .gdbinit
>>
>> I copied my gdbinit on the host to
>>
>> /home/student/BBBworkspace/HelloBBBAutotooled/.gdbinit
>>
>
> Yes, that's where Eclipse's Debug Configuration expects it if you do
not change
> the setting of "GDB Command File" in the Main subtab of the Debugger
tab in
> the Debug configuration.

...

>
>
> Yes, looks like mine except that my target is a MinnowBoard Max and I
> installed my SDK in a different location.

Hmmm

>
>
>> 3) Once you enter the debug view you need to go to the gdb console and:
>>
>> source /home/student/BBBworkspace/HelloBBBAutotooled/.gdbinit
>>
>
> Strange. I don't have to do that if GDB command file is set to the
path in the
> workspace.

Seems to work as well without sourcing ;)

> I would expect that Eclipse passes the .gdbinit from the workspace
> explicitly to GDB. However, I do have
>


> add-auto-load-safe-path .
>
> in my global .gdbinit (~/.gdbinit).

.gdbinit loads automatically for me now, I don't need to source and also
no add-auto-load-safe-path

Which Yocto version do you use? I use 1.8

>
> Cheers,
> Rudi
>

So let's try to summarize what seems to be necessary:

1) right .gdbinit on the right place ;)
2) Debug Configurations -> Debugger -> Main -> Use full file path to set
breakpoints (might not even be necessary)
3) Debug Configurations -> Debugger -> Shared Libraries -> Load shared
library symbols automatically

Regards,

Robert
..."A successful tool is one that was used to do something undreamed of
by its author." - S. C. Johnson

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

Re: gdb/gdbserver vs. eclipse

[Rudolf J Streif]

Hi Robert,
> 
> Which Yocto version do you use? I use 1.8

I am using 1.8, too. Just sent another e-mail about the TCF agent. However, 
that's only in addition since TCF is not used for debugging with GDB. Eclipse 
wraps around GDB which then communicates directly with the GDB server on the 
target.
> So let's try to summarize what seems to be necessary:
> 
> 1) right .gdbinit on the right place ;)

yeap

> 2) Debug Configurations -> Debugger -> Main -> Use full file path to set
> breakpoints (might not even be necessary)

I don't need that.

> 3) Debug Configurations -> Debugger -> Shared Libraries -> Load shared
> library symbols automatically
> 

yeap

Cheers,
Rudi

Re: gdb/gdbserver vs. eclipse

[Rudolf J Streif]

Robert,

What version of Poky/OpenEmbedded Core (meta) are you using?

I found that including Fido (1.8) the tcf-agent built by meta was stuck at 
version 0.4.0. That causes issues with running on the target and getting the 
console output back to Eclipse. That's now updated to 1.3 in master for 
Eclipse Mars. I built 1.2 for Luna which works, but 1.3 works with Luna too.

Cheers,
Rudi

Re: gdb/gdbserver vs. eclipse

[Robert Berger]

On 09/05/2015 09:12 PM, Rudolf J Streif wrote:
> Robert,
> 
> What version of Poky/OpenEmbedded Core (meta) are you using?

I am on the fido branch commit b50596d8f6e858e2e733f2d9913a19c6f3cd5863

plus

my own meta layer (which pulls in a 4.1.2 kernel with my own config) and
I build a core-image-sato-sdk image plus those extras:

EXTRA_IMAGE_FEATURES_append = " debug-tweaks tools-debug tools-sdk
eclipse-debug tools-profile dbg-pkgs"
IMAGE_INSTALL_append = " kernel-vmlinux lttng-tools lttng-modules lttng-ust"
DISTRO_FEATURES_append = " pam"
PACKAGE_DEBUG_SPLIT_STYLE = "debug-file-directory"


> 
> I found that including Fido (1.8) the tcf-agent built by meta was stuck at 
> version 0.4.0. That causes issues with running on the target and getting the 
> console output back to Eclipse. That's now updated to 1.3 in master for 
> Eclipse Mars. I built 1.2 for Luna which works, but 1.3 works with Luna too.
> 
> Cheers,
> Rudi
> 

Regards,

Robert

..."Pascal, at least in its standard form, is just plain not suitable
for serious programming." -- Brian W. Kernighan

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1