RE: [ECOS] Trying to Debug Ecos using GDB

RE: [ECOS] Trying to Debug Ecos using GDB

[Fahd Abidi]

I'm trying to create a test case where I will use a BDI2000 JTAG
emulator to debug the ecos kernel, for that I need an image that has all
the symbols built in. I will then strip the executable to create an
image that does not have any debug symbols to load onto the target, that
way I can debug the kernel thru a JTAG probe. The larger image with
debug symbols is used only on the host GDB and the stipped executable
sits on the target.

Is this possible? Is there any way to tell the linker to leave the debug
symbols in place?

Thanks,

Fahd
 


-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andrew Lunn
Sent: Wednesday, April 12, 2006 4:30 PM
To: Fahd Abidi
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Trying to Debug Ecos using GDB


On Wed, Apr 12, 2006 at 04:23:48PM -0400, Fahd Abidi wrote:
> Thank you very much for that tip. I used an example hello world 
> application and linked it to ecos and have an executable image that 
> can be opened with GDB.
> 
> But now it seems like the executable image only has the symbols built 
> in for my hello.c program and no other kernel source files are 
> present. How can I build the application + library so that debug 
> information for the entire kernel is also present?

Why would you want to do that? 

eCos is designed for embedded systems where memory is short. So linking
to the application leaves out everything that is not used.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss




--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Trying to Debug Ecos using GDB

[Andrew Lunn]

On Wed, Apr 12, 2006 at 04:46:21PM -0400, Fahd Abidi wrote:
> I'm trying to create a test case where I will use a BDI2000 JTAG
> emulator to debug the ecos kernel, for that I need an image that has all
> the symbols built in. I will then strip the executable to create an
> image that does not have any debug symbols to load onto the target, that
> way I can debug the kernel thru a JTAG probe. The larger image with
> debug symbols is used only on the host GDB and the stipped executable
> sits on the target.
> 
> Is this possible? Is there any way to tell the linker to leave the debug
> symbols in place?

After linking with the application to form an image The debug symbols
will be in place, but just symbols you need. The debug information for
symbols that are not in the image will not be in the image.

There is also no need to strip the image before loading it onto the
target. Your BDI2000 will be able to parse the elf image and download
only what is needed onto the target, ie it won't download the debug
information.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Trying to Debug Ecos using GDB

[Grant Edwards]

In gmane.os.ecos.general, you wrote:

> I'm trying to create a test case where I will use a BDI2000 JTAG
> emulator to debug the ecos kernel, for that I need an image that has all
> the symbols built in.

You just have to change the compile flags somewhere.

> I will then strip the executable to create an image that does
> not have any debug symbols to load onto the target,

You don't need to do that.  The debug symbols don't take up
target memory.

> that way I can debug the kernel thru a JTAG probe. The larger
> image with debug symbols is used only on the host GDB and the
> stipped executable sits on the target.

If you're running from RAM, all you have to do is connect via
the JTAG port and load the program using GDB.  GDB will "strip"
the image as it's being loaded into target memory.

> Is this possible? Is there any way to tell the linker to leave
> the debug symbols in place?

IIRC, the trick was to get them there in the first place, but
I may be remembering incorrectly.

-- 
Grant Edwards                   grante             Yow!  .. If I cover this
                                  at               entire WALL with MAZOLA,
                               visi.com            wdo I have to give my AGENT
                                                   ten per cent??

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Trying to Debug Ecos using GDB

[Grant Edwards]

In gmane.os.ecos.general, you wrote:
> On Wed, Apr 12, 2006 at 04:46:21PM -0400, Fahd Abidi wrote:
>> I'm trying to create a test case where I will use a BDI2000 JTAG
>> emulator to debug the ecos kernel, for that I need an image that has all
>> the symbols built in. I will then strip the executable to create an
>> image that does not have any debug symbols to load onto the target, that
>> way I can debug the kernel thru a JTAG probe. The larger image with
>> debug symbols is used only on the host GDB and the stipped executable
>> sits on the target.
>> 
>> Is this possible? Is there any way to tell the linker to leave the debug
>> symbols in place?
>
> After linking with the application to form an image The debug symbols
> will be in place, but just symbols you need. The debug information for
> symbols that are not in the image will not be in the image.

Is the kernel built with debug symbols enabled?  I recall
having to tweak on something to get that enabled.

-- 
Grant Edwards                   grante             Yow!  Do you guys know we
                                  at               just passed thru a BLACK
                               visi.com            HOLE in space?

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Re: Trying to Debug Ecos using GDB

[Fahd Abidi]

My Sincerest apologies to everyone. I had been opening hello.o with gdb
not hello.elf, hello .elf has all the symbols built into it. Thanks for
all your support and sorry about wasting your time.  :(

Fahd

-----Original Message-----
From: nickg@xl5.calivar.com [mailto:nickg@xl5.calivar.com] On Behalf Of
Nick Garnett
Sent: Thursday, April 13, 2006 5:46 AM
To: Fahd Abidi
Cc: Grant Edwards; ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Re: Trying to Debug Ecos using GDB


"Fahd Abidi" <fabidi@ultsol.com> writes:

> Yes the kernel is built with debug symbols. I checked the libtarget.a 
> file with objdump -s and saw disassembly and source code. So its in 
> there. Libtarget.a is 17mb, if I strip it of symbols using objcopy -g 
> then it drops to 1.7mb.
> 
> When I go to the steps of linking with my application the final hello 
> executable leaves out the symbols from the kernel.
> 
> I may not be following what Andrew is saying, as far as I can tell I 
> have included the debug symbols from all Parts of the kernel that are 
> used, the appropriate setting in the kernel to enable debug bits is 
> set. The -g CFLAG bit is set in the top level of the ecos project, so 
> all debug symbols should be added.
> 
> The resulting hello executable only has source info for hello.c no 
> other sources are in that executable. I checked the compiler output 
> and saw the -g flag getting passed to the application as well.

How are you detecting that the symbols are not there? Full debug info
should be included in the executable by default.

If I run nm on a typical test executable I see all the kernel symbols.
For example:

$ arm-elf-nm -CSn tm_basic | grep Cyg_Thread
62007de4 00000564 T Cyg_Thread::Cyg_Thread(unsigned int, void
(*)(unsigned int), unsigned int, char*, unsigned int, unsigned int)
62008348 00000564 T Cyg_Thread::Cyg_Thread(unsigned int, void
(*)(unsigned int), unsigned int, char*, unsigned int, unsigned int)
620088ac 00000088 T Cyg_Thread::check_this(cyg_assert_class_zeal) const
62008934 00000180 T Cyg_Thread::reinitialize() 62008ab4 00000130 T
Cyg_Thread::~Cyg_Thread() 62008be4 00000130 T Cyg_Thread::~Cyg_Thread()
62008d14 00000064 T Cyg_Thread::exit() 62008d78 00000034 T
Cyg_HardwareThread::thread_entry(Cyg_Thread*)
62008dac 00000118 T Cyg_Thread::sleep()
62008ec4 00000108 T Cyg_Thread::wake()
62008fcc 00000128 T Cyg_Thread::suspend()
620090f4 00000120 T Cyg_Thread::resume()
62009214 0000011c T Cyg_Thread::force_resume()
62009330 0000014c T Cyg_Thread::kill()
6200947c 00000224 T Cyg_Thread::set_priority(int)
620096a0 0000011c T Cyg_Thread::delay(unsigned long long) 620097bc
00000020 T Cyg_Thread::deliver_exception(int, unsigned int) 620097dc
0000010c T Cyg_ThreadTimer::alarm(Cyg_Alarm*, unsigned int) 62009a98
00000010 t
_GLOBAL__I.11100__ZN18Cyg_HardwareThread12thread_entryEP10Cyg_Thread
62009aa8 00000010 t
_GLOBAL__D.11100__ZN18Cyg_HardwareThread12thread_entryEP10Cyg_Thread
6200a154 0000003c T Cyg_ThreadQueue_Implementation::enqueue(Cyg_Thread*)
6200a190 00000078 T Cyg_ThreadQueue_Implementation::remove(Cyg_Thread*)
6200a460 00000040 T
Cyg_Scheduler_Implementation::set_need_reschedule(Cyg_Thread*)
6200a4a0 000002e4 T
Cyg_Scheduler_Implementation::add_thread(Cyg_Thread*)
6200a784 000001e8 T
Cyg_Scheduler_Implementation::rem_thread(Cyg_Thread*)
6200a96c 00000014 T
Cyg_Scheduler_Implementation::set_idle_thread(Cyg_Thread*, unsigned int)
6200a980 00000004 T
Cyg_Scheduler_Implementation::register_thread(Cyg_Thread*)
6200a984 00000004 T
Cyg_Scheduler_Implementation::deregister_thread(Cyg_Thread*)
6200ad38 00000054 T Cyg_ThreadQueue_Implementation::dequeue()
6200b488 000000e8 T Cyg_Scheduler::thread_entry(Cyg_Thread*)
6200b668 0000002c T Cyg_SchedThread::Cyg_SchedThread(Cyg_Thread*,
unsigned int) 6200b694 00000090 T
Cyg_SchedThread::set_inherited_priority(int, Cyg_Thread*) 6200b724
00000018 T Cyg_SchedThread::relay_inherited_priority(Cyg_Thread*,
Cyg_ThreadQueue*) 6200b7d4 000000b0 T
Cyg_SchedThread::inherit_priority(Cyg_Thread*)
6200b884 00000004 T Cyg_SchedThread::relay_priority(Cyg_Thread*,
Cyg_ThreadQueue*) 620135ac 00000020 r
Cyg_Thread::reinitialize()::__PRETTY_FUNCTION__
620135cc 00000020 r Cyg_Thread::sleep()::__PRETTY_FUNCTION__
620135ec 0000001b r Cyg_Thread::suspend()::__PRETTY_FUNCTION__
62013608 0000001a r Cyg_Thread::resume()::__PRETTY_FUNCTION__
62013624 00000020 r Cyg_Thread::force_resume()::__PRETTY_FUNCTION__
62013644 0000002c r Cyg_Thread::set_priority(int)::__PRETTY_FUNCTION__
62013b94 0000003b r
Cyg_Scheduler_Implementation::add_thread(Cyg_Thread*)::__PRETTY_FUNCTION
__
62013bd0 0000003b r
Cyg_Scheduler_Implementation::rem_thread(Cyg_Thread*)::__PRETTY_FUNCTION
__
62013f2c 00000048 r Cyg_SchedThread::set_inherited_priority(int,
Cyg_Thread*)::__PRETTY_FUNCTION__ 62013fa8 00000034 r
Cyg_SchedThread::inherit_priority(Cyg_Thread*)::__PRETTY_FUNCTION__
62015024 00000004 D Cyg_Thread::thread_list
621a736c 00000008 B Cyg_Thread::exception_control


What happens if you try that on your hello executable?


-- 
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts




--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Trying to Debug Ecos using GDB

[Nick Garnett]

"Fahd Abidi" <fabidi@ultsol.com> writes:

> Yes the kernel is built with debug symbols. I checked the libtarget.a
> file with objdump -s and saw disassembly and source code. So its in
> there. Libtarget.a is 17mb, if I strip it of symbols using objcopy -g
> then it drops to 1.7mb.
> 
> When I go to the steps of linking with my application the final hello
> executable leaves out the symbols from the kernel.
> 
> I may not be following what Andrew is saying, as far as I can tell I
> have included the debug symbols from all Parts of the kernel that are
> used, the appropriate setting in the kernel to enable debug bits is set.
> The -g CFLAG bit is set in the top level of the ecos project, so all
> debug symbols should be added.
> 
> The resulting hello executable only has source info for hello.c no other
> sources are in that executable. I checked the compiler output and saw
> the -g flag getting passed to the application as well.

How are you detecting that the symbols are not there? Full debug info
should be included in the executable by default.

If I run nm on a typical test executable I see all the kernel
symbols. For example:

$ arm-elf-nm -CSn tm_basic | grep Cyg_Thread
62007de4 00000564 T Cyg_Thread::Cyg_Thread(unsigned int, void (*)(unsigned int), unsigned int, char*, unsigned int, unsigned int)
62008348 00000564 T Cyg_Thread::Cyg_Thread(unsigned int, void (*)(unsigned int), unsigned int, char*, unsigned int, unsigned int)
620088ac 00000088 T Cyg_Thread::check_this(cyg_assert_class_zeal) const
62008934 00000180 T Cyg_Thread::reinitialize()
62008ab4 00000130 T Cyg_Thread::~Cyg_Thread()
62008be4 00000130 T Cyg_Thread::~Cyg_Thread()
62008d14 00000064 T Cyg_Thread::exit()
62008d78 00000034 T Cyg_HardwareThread::thread_entry(Cyg_Thread*)
62008dac 00000118 T Cyg_Thread::sleep()
62008ec4 00000108 T Cyg_Thread::wake()
62008fcc 00000128 T Cyg_Thread::suspend()
620090f4 00000120 T Cyg_Thread::resume()
62009214 0000011c T Cyg_Thread::force_resume()
62009330 0000014c T Cyg_Thread::kill()
6200947c 00000224 T Cyg_Thread::set_priority(int)
620096a0 0000011c T Cyg_Thread::delay(unsigned long long)
620097bc 00000020 T Cyg_Thread::deliver_exception(int, unsigned int)
620097dc 0000010c T Cyg_ThreadTimer::alarm(Cyg_Alarm*, unsigned int)
62009a98 00000010 t _GLOBAL__I.11100__ZN18Cyg_HardwareThread12thread_entryEP10Cyg_Thread
62009aa8 00000010 t _GLOBAL__D.11100__ZN18Cyg_HardwareThread12thread_entryEP10Cyg_Thread
6200a154 0000003c T Cyg_ThreadQueue_Implementation::enqueue(Cyg_Thread*)
6200a190 00000078 T Cyg_ThreadQueue_Implementation::remove(Cyg_Thread*)
6200a460 00000040 T Cyg_Scheduler_Implementation::set_need_reschedule(Cyg_Thread*)
6200a4a0 000002e4 T Cyg_Scheduler_Implementation::add_thread(Cyg_Thread*)
6200a784 000001e8 T Cyg_Scheduler_Implementation::rem_thread(Cyg_Thread*)
6200a96c 00000014 T Cyg_Scheduler_Implementation::set_idle_thread(Cyg_Thread*, unsigned int)
6200a980 00000004 T Cyg_Scheduler_Implementation::register_thread(Cyg_Thread*)
6200a984 00000004 T Cyg_Scheduler_Implementation::deregister_thread(Cyg_Thread*)
6200ad38 00000054 T Cyg_ThreadQueue_Implementation::dequeue()
6200b488 000000e8 T Cyg_Scheduler::thread_entry(Cyg_Thread*)
6200b668 0000002c T Cyg_SchedThread::Cyg_SchedThread(Cyg_Thread*, unsigned int)
6200b694 00000090 T Cyg_SchedThread::set_inherited_priority(int, Cyg_Thread*)
6200b724 00000018 T Cyg_SchedThread::relay_inherited_priority(Cyg_Thread*, Cyg_ThreadQueue*)
6200b7d4 000000b0 T Cyg_SchedThread::inherit_priority(Cyg_Thread*)
6200b884 00000004 T Cyg_SchedThread::relay_priority(Cyg_Thread*, Cyg_ThreadQueue*)
620135ac 00000020 r Cyg_Thread::reinitialize()::__PRETTY_FUNCTION__
620135cc 00000020 r Cyg_Thread::sleep()::__PRETTY_FUNCTION__
620135ec 0000001b r Cyg_Thread::suspend()::__PRETTY_FUNCTION__
62013608 0000001a r Cyg_Thread::resume()::__PRETTY_FUNCTION__
62013624 00000020 r Cyg_Thread::force_resume()::__PRETTY_FUNCTION__
62013644 0000002c r Cyg_Thread::set_priority(int)::__PRETTY_FUNCTION__
62013b94 0000003b r Cyg_Scheduler_Implementation::add_thread(Cyg_Thread*)::__PRETTY_FUNCTION__
62013bd0 0000003b r Cyg_Scheduler_Implementation::rem_thread(Cyg_Thread*)::__PRETTY_FUNCTION__
62013f2c 00000048 r Cyg_SchedThread::set_inherited_priority(int, Cyg_Thread*)::__PRETTY_FUNCTION__
62013fa8 00000034 r Cyg_SchedThread::inherit_priority(Cyg_Thread*)::__PRETTY_FUNCTION__
62015024 00000004 D Cyg_Thread::thread_list
621a736c 00000008 B Cyg_Thread::exception_control


What happens if you try that on your hello executable?


-- 
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Re: Trying to Debug Ecos using GDB

[Fahd Abidi]

Yes the kernel is built with debug symbols. I checked the libtarget.a
file with objdump -s and saw disassembly and source code. So its in
there. Libtarget.a is 17mb, if I strip it of symbols using objcopy -g
then it drops to 1.7mb.

When I go to the steps of linking with my application the final hello
executable leaves out the symbols from the kernel.

I may not be following what Andrew is saying, as far as I can tell I
have included the debug symbols from all Parts of the kernel that are
used, the appropriate setting in the kernel to enable debug bits is set.
The -g CFLAG bit is set in the top level of the ecos project, so all
debug symbols should be added.

The resulting hello executable only has source info for hello.c no other
sources are in that executable. I checked the compiler output and saw
the -g flag getting passed to the application as well.

Thanks for all you help in getting to the bottom of this. I need to get
an executable that has kernel debug info, it seems like you were able to
create one at some point. Any tips or pointers you can give will be most
appreciated. I am including the output of the make file, maybe you guys
can spot something in there:

$ make
powerpc-eabi-gcc -c -g -mcpu=603e -Wall -Wpointer-arith
-Wstrict-prototypes -Win
line -Wundef -Woverloaded-virtual -g -O2 -ffunction-sections
-fdata-sections -fn
o-rtti -fno-exceptions -fvtable-gc -finit-priority
-I/ecos-c/cygwin/home/ecos/ra
ttler8250/rattler8250_install/include hello.c
powerpc-eabi-gcc -g -mcpu=603e -g -nostdlib -Wl,--gc-sections
-Wl,-static -L/eco
s-c/cygwin/home/ecos/rattler8250/rattler8250_install/lib -Ttarget.ld
hello.o -o
hello

Thanks,

Fahd
 


-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Grant
Edwards
Sent: Wednesday, April 12, 2006 6:16 PM
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] Re: Trying to Debug Ecos using GDB


In gmane.os.ecos.general, you wrote:
> On Wed, Apr 12, 2006 at 04:46:21PM -0400, Fahd Abidi wrote:
>> I'm trying to create a test case where I will use a BDI2000 JTAG 
>> emulator to debug the ecos kernel, for that I need an image that has 
>> all the symbols built in. I will then strip the executable to create 
>> an image that does not have any debug symbols to load onto the 
>> target, that way I can debug the kernel thru a JTAG probe. The larger

>> image with debug symbols is used only on the host GDB and the stipped

>> executable sits on the target.
>> 
>> Is this possible? Is there any way to tell the linker to leave the 
>> debug symbols in place?
>
> After linking with the application to form an image The debug symbols 
> will be in place, but just symbols you need. The debug information for

> symbols that are not in the image will not be in the image.

Is the kernel built with debug symbols enabled?  I recall having to
tweak on something to get that enabled.

-- 
Grant Edwards                   grante             Yow!  Do you guys
know we
                                  at               just passed thru a
BLACK
                               visi.com            HOLE in space?

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss






--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Trying to Debug Ecos using GDB

[Grant Edwards]

In gmane.os.ecos.general, you wrote:
> On Wed, Apr 12, 2006 at 04:23:48PM -0400, Fahd Abidi wrote:
>> Thank you very much for that tip. I used an example hello world
>> application and linked it to ecos and have an executable image that can
>> be opened with GDB.
>> 
>> But now it seems like the executable image only has the symbols built in
>> for my hello.c program and no other kernel source files are present. How
>> can I build the application + library so that debug information for the
>> entire kernel is also present?
>
> Why would you want to do that? 
>
> eCos is designed for embedded systems where memory is short.

The presence or absense of debug info in the ELF file has no
impact on the footprint of the image.  I used to enable
debug symbols for kernel files when I was troubleshooting
eCos internal stuff, and it didn't require any more memory.

> So linking to the application leaves out everything that is
> not used.

True, but his problem is that he wants debug info for the stuff
that is used.

-- 
Grant Edwards                   grante             Yow!  It's so OBVIOUS!!
                                  at               
                               visi.com            

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss