gdb problems

gdb problems

[Joakim Tjernlund]

Hi

I am trying to debug ppclinux 2.4 and ppcboot on RPX CLLF board
connected to an Abatron emulator.

When I print variables in gdb I get an <error type> message
instead of the variable value. Breakpoints and stack trace etc. works
fine. I have enabled -g switch to gcc.

Any ideas?

 Jocke

I am using Montavistas CDK 1.2 on RH7.1

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: gdb problems

[Wolfgang Denk]

In message <IGEFJKJNHJDCBKALBJLLGEDNENAA.joakim.tjernlund@lumentis.se> you wrote:
>
> I am trying to debug ppclinux 2.4 and ppcboot on RPX CLLF board
> connected to an Abatron emulator.

Did you invalidate the M_TWB in the BDI config file ("WSPR  796  0"),
and did you enable address translation ("MMU XLAT") ?

> When I print variables in gdb I get an <error type> message

And what was the EXACT error message?

> instead of the variable value. Breakpoints and stack trace etc. works
> fine. I have enabled -g switch to gcc.

Which version of GDB are you using, and which firmware version of the
BDI2000? (b20ppcgd.108 has been out for some time).

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The typical page layout program is nothing more  than  an  electronic
light table for cutting and pasting documents.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: gdb problems

[Scott Anderson]

Joakim Tjernlund wrote:
>
> Hi
>
> I am trying to debug ppclinux 2.4 and ppcboot on RPX CLLF board
> connected to an Abatron emulator.
>
> When I print variables in gdb I get an <error type> message
> instead of the variable value. Breakpoints and stack trace etc. works
> fine. I have enabled -g switch to gcc.

In order to get gdb to understand structs, etc. I compile with -ggdb
instead of -g.  Works quite well.  I'm spoiled now.

    Scott Anderson
    scott_anderson@mvista.com   MontaVista Software Inc.
    (408)328-9214               1237 East Arques Ave.
    http://www.mvista.com       Sunnyvale, CA  94085

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: gdb problems

[Wolfgang Denk]

In message <000701c0d99b$357cbf20$3196143e@jocke> you wrote:
>
> > Which version of GDB are you using, and which firmware version of the
...
> >From the MontaVista CDK 1.2, ppc_8xx-gdb-5.0-1 and ppc_8xx-gcc-2.95.2-13

Ummm... I tried this once, and it barfed on all my macro definitions.
Something must be seriously broken with this version of GDB. I  would
not trust it a signle step :-(

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Another megabytes the dust.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: gdb problems

[Joakim Tjernlund]

Thanks, that did the trick.

One small problem though. When I added -ggdb gcc complained about:
"Error: relocation can not be done when using -mrelocatable"

This is when I compile ppcboot. When I removed -mrelocateable, it compiled.

Why is this?

 Jocke

> In order to get gdb to understand structs, etc. I compile with -ggdb
> instead of -g.  Works quite well.  I'm spoiled now.
>
>     Scott Anderson
>     scott_anderson@mvista.com   MontaVista Software Inc.
>     (408)328-9214               1237 East Arques Ave.
>     http://www.mvista.com       Sunnyvale, CA  94085

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: gdb problems

[Joakim Tjernlund]

hmm, I guess I should upgrade then. Any idea when Mvista will release
hhl 2.0?

 Jocke

>
> Ummm... I tried this once, and it barfed on all my macro definitions.
> Something must be seriously broken with this version of GDB. I  would
> not trust it a signle step :-(
>
> Wolfgang Denk
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: gdb problems

[Joakim Tjernlund]

Hi again

Next small problem:

How do i get gdb to debug assembler files?
if i do "list _start" in gdb i get a:
No line number information avaiable for address 0xfc0100 <_start>

I have tried a different gdb debuggers and options to gcc

    Jocke

> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@lumentis.se]
> Sent: Friday, May 11, 2001 12:24
> To: Scott Anderson
> Cc: linuxppc-embedded@lists.linuxppc.org
> Subject: RE: gdb problems
>
>
> Thanks, that did the trick.
>
> One small problem though. When I added -ggdb gcc complained about:
> "Error: relocation can not be done when using -mrelocatable"
>
> This is when I compile ppcboot. When I removed -mrelocateable, it
> compiled.
>
> Why is this?
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

gdb problems

[Christopher R. Johnson]

Maybe not the right list for this, if you have a suggestion for
somewhere better let me know...

My new tool chain build is working well, except that debugging with
gdb/gdbserver is somewhat broken.  I figured out that I needed thread_db
and have that built in now and delivered to the target platform.

Problem #1: When I start host side gdb, I get the message:
warning: unable to find dynamic linker breakpoint function
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code

I don't need to debug initializers, so I set a breakpoint at main and
continue.  Two error messages appear:
Error while mapping shared library sections:
/lib/ld.so.1: No such file or directory
Error while mapping shared library symbols:
/lib/ld.so.1: No such file or directory

The program starts and breakpoint don't work.

Problem #2:  (Maybe related?) on the target side gdbserver, after
starting things with "c" on the host side, this message appears:
gdb: error initializing thread_db library.
gdb: error initializing thread_db library.

Yes, twice.

Why is the host side looking in /lib for target libraries?  Can I
control that?  How?

Why is gdbserver on the target having trouble?  I see I have correctly
delivered the thread_db library in /lib on the target, so what gives?

Any help or guidance would be greatly appreciated.  I build my toolchain
with crosstools.

--
Christopher R. Johnson


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: gdb problems

[Christopher R. Johnson]

Ok, answering some of my own questions:

in host-side gdb, use the two commands:
set solib-absolute-prefix
set solib-search-path

I set the first to /dev/null and the second to the path where my
filesystem is constructed and its /lib directory (where all my shared
libs are on the host).

All the below error messages go away, but I am left with my original
problem.  I can set breakpoints but they don't work.  What am I missing?

Christopher R. Johnson wrote:

>
> Maybe not the right list for this, if you have a suggestion for
> somewhere better let me know...
>
> My new tool chain build is working well, except that debugging with
> gdb/gdbserver is somewhat broken.  I figured out that I needed thread_db
> and have that built in now and delivered to the target platform.
>
> Problem #1: When I start host side gdb, I get the message:
> warning: unable to find dynamic linker breakpoint function
> GDB will be unable to debug shared library initializers
> and track explicitly loaded dynamic code
>
> I don't need to debug initializers, so I set a breakpoint at main and
> continue.  Two error messages appear:
> Error while mapping shared library sections:
> /lib/ld.so.1: No such file or directory
> Error while mapping shared library symbols:
> /lib/ld.so.1: No such file or directory
>
> The program starts and breakpoint don't work.
>
> Problem #2:  (Maybe related?) on the target side gdbserver, after
> starting things with "c" on the host side, this message appears:
> gdb: error initializing thread_db library.
> gdb: error initializing thread_db library.
>
> Yes, twice.
>
> Why is the host side looking in /lib for target libraries?  Can I
> control that?  How?
>
> Why is gdbserver on the target having trouble?  I see I have correctly
> delivered the thread_db library in /lib on the target, so what gives?
>
> Any help or guidance would be greatly appreciated.  I build my toolchain
> with crosstools.
>
> --
> Christopher R. Johnson
>
>
>

--
Christopher R. Johnson
Principal Software Engineer
GCC Printers
(781)276-8763


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: gdb problems

[Wolfgang Denk]

In message <4016965F.5060706@gcctech.com> you wrote:
>
> Problem #1: When I start host side gdb, I get the message:
> warning: unable to find dynamic linker breakpoint function
> GDB will be unable to debug shared library initializers
> and track explicitly loaded dynamic code

You missed to set solib-absolute-prefix - see
http://www.denx.de/twiki/bin/view/DULG/DebuggingApplication#Section_9.5.2.

> The program starts and breakpoint don't work.
>
> Problem #2:  (Maybe related?) on the target side gdbserver, after
> starting things with "c" on the host side, this message appears:
> gdb: error initializing thread_db library.
> gdb: error initializing thread_db library.
>
> Yes, twice.

Well, guess what that means?

> Why is gdbserver on the target having trouble?  I see I have correctly
> delivered the thread_db library in /lib on the target, so what gives?

Probably you have other problems with your build of GDB /  gdbserver.
We had to fix a couple of problems to get thread support working.

> Any help or guidance would be greatly appreciated.  I build my toolchain
> with crosstools.

Feel free to try out the GDB / gdbserver that come with the ELDK.

Best regards,

Wolfgang Denk

--
See us @ Embedded World, Nuremberg, Feb 17 - 19,  Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The moral of the story is: "Don't stop to  tighten  your  shoe  laces
during the Olympics 100m finals".
                             - Kevin Jones in <DEJo68.K1t@bri.hp.com>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

GDB problems

[Gary Thomas]

I'm trying to run GDB to debug code on my target.  Whenever I start
it up, I get this warning:
   warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
and indeed, no thread debug commands will work.

I've found that the library /usr/lib/libthread_db.so is not being
installed in the rootfs.  However, just adding this library isn't
enough.  The file /lib/libpthread-2.60.so has been stripped on the
target and this also breaks GDB.  Installing a non-stripped version
of this library lets GDB do thread debugging.

Both of these libraries come from the eglibc package.  How can I
adjust that recipe to:
   * Install libthread_db.so
   * Avoid stripping libpthread-2.16.so

It looks like the libthread_db.so file(s) should be installed via
the 'eglibc-thread-db' package, but I can't find this package anywhere
on my system.

Any pointers?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: GDB problems

[Gary Thomas]

On 2013-04-08 05:03, Gary Thomas wrote:
> I'm trying to run GDB to debug code on my target.  Whenever I start
> it up, I get this warning:
>    warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
> and indeed, no thread debug commands will work.
>
> I've found that the library /usr/lib/libthread_db.so is not being
> installed in the rootfs.  However, just adding this library isn't
> enough.  The file /lib/libpthread-2.60.so has been stripped on the
> target and this also breaks GDB.  Installing a non-stripped version
> of this library lets GDB do thread debugging.
>
> Both of these libraries come from the eglibc package.  How can I
> adjust that recipe to:
>    * Install libthread_db.so
>    * Avoid stripping libpthread-2.16.so
>
> It looks like the libthread_db.so file(s) should be installed via
> the 'eglibc-thread-db' package, but I can't find this package anywhere
> on my system.

It's not clear to me why, but the files labelled as 'eglibc-thread-db' in
the eglibc recipe end up in the 'libthread-db1' package, so that mystery
is solved.

I still don't know how to get the libpthread library to be not stripped
(which it seems is what it takes to make GDB happy in this case).

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: GDB problems

[Paul Eggleton]

On Monday 08 April 2013 06:30:02 Gary Thomas wrote:
> On 2013-04-08 05:03, Gary Thomas wrote:
> > I'm trying to run GDB to debug code on my target.  Whenever I start
> > 
> > it up, I get this warning:
> >    warning: Unable to find libthread_db matching inferior's thread
> >    library, thread debugging will not be available.> 
> > and indeed, no thread debug commands will work.
> > 
> > I've found that the library /usr/lib/libthread_db.so is not being
> > installed in the rootfs.  However, just adding this library isn't
> > enough.  The file /lib/libpthread-2.60.so has been stripped on the
> > target and this also breaks GDB.  Installing a non-stripped version
> > of this library lets GDB do thread debugging.
> > 
> > Both of these libraries come from the eglibc package.  How can I
> > 
> > adjust that recipe to:
> >    * Install libthread_db.so
> >    * Avoid stripping libpthread-2.16.so

Does installing eglibc-dbg help with this? (Assuming you don't have this 
installed already.)

> > It looks like the libthread_db.so file(s) should be installed via
> > the 'eglibc-thread-db' package, but I can't find this package anywhere
> > on my system.
> 
> It's not clear to me why, but the files labelled as 'eglibc-thread-db' in
> the eglibc recipe end up in the 'libthread-db1' package, so that mystery
> is solved.

That is debian library package renaming (debian.bbclass).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: GDB problems

[Gary Thomas]

On 2013-04-08 06:47, Paul Eggleton wrote:
> On Monday 08 April 2013 06:30:02 Gary Thomas wrote:
>> On 2013-04-08 05:03, Gary Thomas wrote:
>>> I'm trying to run GDB to debug code on my target.  Whenever I start
>>>
>>> it up, I get this warning:
>>>     warning: Unable to find libthread_db matching inferior's thread
>>>     library, thread debugging will not be available.>
>>> and indeed, no thread debug commands will work.
>>>
>>> I've found that the library /usr/lib/libthread_db.so is not being
>>> installed in the rootfs.  However, just adding this library isn't
>>> enough.  The file /lib/libpthread-2.60.so has been stripped on the
>>> target and this also breaks GDB.  Installing a non-stripped version
>>> of this library lets GDB do thread debugging.
>>>
>>> Both of these libraries come from the eglibc package.  How can I
>>>
>>> adjust that recipe to:
>>>     * Install libthread_db.so
>>>     * Avoid stripping libpthread-2.16.so
>
> Does installing eglibc-dbg help with this? (Assuming you don't have this
> installed already.)

Yes, although it's named 'libc6-dbg'

>
>>> It looks like the libthread_db.so file(s) should be installed via
>>> the 'eglibc-thread-db' package, but I can't find this package anywhere
>>> on my system.
>>
>> It's not clear to me why, but the files labelled as 'eglibc-thread-db' in
>> the eglibc recipe end up in the 'libthread-db1' package, so that mystery
>> is solved.
>
> That is debian library package renaming (debian.bbclass).

Ah, black magic...

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: GDB problems

[Khem Raj]

On Apr 8, 2013, at 5:47 AM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:

> Does installing eglibc-dbg help with this? (Assuming you don't have this 
> installed already.)

libc6-dev should be enough. You do not need -dbg one. If it does not work with -dev
then we have a problem.