This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
GDB-Monitor questions
- From: "Martin Laabs" <martin dot laabs at mailbox dot tu-dresden dot de>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Sun, 23 Mar 2008 20:58:02 +0100
- Subject: [ECOS] GDB-Monitor questions
Hi,
today I ported eCos on my LPC2119 board. Redboot and some test application
works fine.
Because redboot uses almost the whole RAM i can't use it for source-level
debugging. Now I build a gdb stub that uses about 6k RAM and 24k Flash -
much mor usable than redboot. (But 6k RAM usage is still much since the
device has only 16kB.)
However - since most application won't fit in the remaining RAM I'd like
to debug the "user"-application from flash.
I had two ideas how to realize that. The first idea was to build the
libtarget.a with source-level debug support. With such a 'libtarget.a' I
could just write my application, link it together and debug it via the
serial channel since the gdb-stub is included in the libtarget.a.
I tried that - but unfortunately this did not work - I don't know whether
I made a mistake or this is impossible in principal The images I created
this way just printed a '+' and did not communicate further. (Althougt the
"standalone" gdb_module image worked absolute ok.) Has anyone an idea why
this did not worked?
The second idea was to build the gdb stub the conventinonal way and
download the gdb_module image to the target.
The user-application should get a different linker script to use only the
ram and flash sectors that are unused. One advantage of that way would be
a faster download since I wouldn't had to download the gdb-stub every
time. Did anyone ever realized such a scenario?
Thank you,
Martin L.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss