This is the mail archive of the
mailing list for the GDB project.
Fw: self decompressing code
- From: "Jafa" <jafa at silicondust dot com>
- To: <gdb at sources dot redhat dot com>
- Date: Sat, 12 Apr 2003 13:39:25 -0700
- Subject: Fw: self decompressing code
> Jafa wrote:
> > Hi all,
> > This isn't a problem with GDB but I would appreciate your advice on a
> > model....
> > The ip2k is an embedded processor and we compile a single elf file to be
> > used to program and debug the ip2k which executes out of internal flash.
> > External flash can also be used and I have just added code to
> > to program external flash.
> > The image that is uploaded to external flash is a compressed upgrade
> > When the chip boots up it will decompress code/data to internal flash
> > external flash.
> > This scheme works well except for two problems:
> > 1) GDB downloads the .text section even though it is not needed and is
> > overwritten. If I change the section flags such that the .text section
> > not loadable then GDB complains that it can't debug the file.
> What's in the text section that isn't needed?
> Can you just create a dummy text section that is small,
> so that it won't take long to DL and can be ignored?
The text section is the code for the application - the code that I want to
debug. The problem is that GDB wants to load it into memory itself (which
takes time) and the startup code will initialize the text section itself
anyway by decompressing from external flash (which gdb also programmed). I
could specify a different load address but in this case the load data is
> > 2) Any breakpoints that are inserted are overwritten - I need to add a
> > on the reset vector.
> I don't understand -- why would any breakpoints be inserted at the
> time when you're doing a download? GDB only inserts breakpoints
> when the program being debugged is running.
After loading, the user sets breakpoints and runs (causing gdb to insert
them). The startup code then decompresses the text section thus overwriting
the software breakpoints.
> > Ideas so far:
> > 1) Modify the upgrade/decompression code so that it doesn't write the
> > internal flash. This would solve the breakpoint problem but is noticably
> > slower (it is faster to upload the compressed image) and the scheme will
> > difficult to modify.
> > 2) Modify gdb so it ignores the fact that the .text section isn't
> > Add an auto-inserted breakpoint on the reset vector.
> > If you have any thoughts or ideas I would appreciate the advice.
> Why can't you just set a normal gdb breakpoint on the reset vector?
That was my thinking as well.