> >> If the section addresses does not match the actual
> memory layout of
> >> the target, there's nothing gdb can do about it.
> >
> > I disagree; gdb can certainly discover this has, and must have, the offset.
> > It's
GDB runs by the memory map that OpenOCD feeds it
during startup. That memory map is not, ISTR,
necessarily correct about where ram is found.
There's an RFE in our bug database about wanting
to at least add a way to declare where RAM lives,
so that can be fed to GDB..
> probably
> mainly useful when you load a binary file without location
> information
> encoded in the file. When you load an elf-file, all
> information gdb
> needs is already available from the file.
Sometimes. If it was part of the linker script
used to create the ELF image.
There don't seem to be public archives of linker
scripts for Cortex-M parts, specifying where flash
and SRAM regions are found. So folk need to write
their own (possibly buggy) ones...
>
> It can never be made automatic. Consider if my target
> actually HAS
> some memory at address zero that I want to load and gdb has
> been
> patched as a result of this discussion to automatically add
> 0x8000000
> to the load address if it equals zero. It would break my
> system. Can
> you find another method of altering gdb that would resolve
> this issue
> while not breaking any conceivable valid configuration and
> not producing nonsense error messages
Download comoplete target memory maps to GDB,
not the partial (and ISTR made-up/wrong) one
it now delivers ... Knock off that RFE...
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
