This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: self decompressing code
- From: Michael Snyder <msnyder at redhat dot com>
- To: Jafa <jafa at silicondust dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Sat, 12 Apr 2003 12:54:54 -0700
- Subject: Re: self decompressing code
- Organization: Red Hat, Inc.
- References: <043701c3004a$49ca4b00$f601a8c0@scenix.com>
Jafa wrote:
>
> Hi all,
>
> This isn't a problem with GDB but I would appreciate your advice on a usage
> 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 remote-ip2k.c
> to program external flash.
>
> The image that is uploaded to external flash is a compressed upgrade image.
> When the chip boots up it will decompress code/data to internal flash and
> 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 is
> 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?
> 2) Any breakpoints that are inserted are overwritten - I need to add a break
> 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.
> 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 be
> difficult to modify.
> 2) Modify gdb so it ignores the fact that the .text section isn't loadable.
> 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?