public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* self decompressing code
@ 2003-04-11 16:51 Jafa
  2003-04-12 19:54 ` Michael Snyder
  0 siblings, 1 reply; 2+ messages in thread
From: Jafa @ 2003-04-11 16:51 UTC (permalink / raw)
  To: gdb

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.
2) Any breakpoints that are inserted are overwritten - I need to add a break
on the reset vector.

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.

BTW - I wrote the second-generation ip2k GDB port... I am happy teaching gdb
anything.

Nick


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: self decompressing code
  2003-04-11 16:51 self decompressing code Jafa
@ 2003-04-12 19:54 ` Michael Snyder
  0 siblings, 0 replies; 2+ messages in thread
From: Michael Snyder @ 2003-04-12 19:54 UTC (permalink / raw)
  To: Jafa; +Cc: gdb

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?

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-04-12 19:54 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-11 16:51 self decompressing code Jafa
2003-04-12 19:54 ` Michael Snyder

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).