On Sat, Sep 4, 2010 at 2:57 PM, Peter Stuge <pe...@stuge.se> wrote: > Øyvind Harboe wrote: >> Perhaps this is a thing that *should* be a bit hard? >> >> Perhaps embedded users *should* learn about the load offset for >> GDB? > > Do you know if gdb always sends an offset in the (binary?) command to > OpenOCD? If yes, I think gdb should be changed to make 'load' easier > to use.
This is not a problem with gdb. When gdb is asked to load an image it simply writes all relevant sections in that image to their respective memory locations. If it has knowledge that the location to be written resides in flash, it uses the vFlash* commands, otherwise it uses regular memory writes. If the section addresses does not match the actual memory layout of the target, there's nothing gdb can do about it. Yes, you can fix the error by telling gdb to load the image with an offset. That won't change the fact that the image is not linked correctly and gdb can hardly be blamed for providing the possibility of a workaround. Nor is it an OpenOCD problem. We just provide the knowledge to gdb about the memory layout of the target and then receive the memory writes. We can't guess the user's intentions and try to remap the writes behind gdb's (and the user's) back. > Can OpenOCD return a (textual?) error message? If yes, then OpenOCD > could return a very informative error in case someone tries to load > to an address not backed by flash. We can't really tell the (non-flash) loads from other memory writes and we don't want to see errors on every write to peripheral or sram addresses. Even if we could we wouldn't want to print an error, because there is no error. And what would the message look like? "It seems you're trying to load an image to a memory location not commonly used for loading to. Maybe you're using a broken linker script. Do you want me to try to fix the script for you?" That would be neat. Why not take it a step further? "I notice you try to load an image that has been compiled for another architecture than the one you're working on. Do you want me to install the correct cross compiler and recompile it for you?" "Based on your recent usage pattern I've come to the conclusion that you're getting desperate to find that nasty bug you introduced two weeks ago, before your deadline tomorrow morning. It's really late, so why don't you go home and get some sleep and I'll fix the bug for you." "It looks like you're writing a letter. Would you like help?" Aaargh! Ok maybe not such a great idea. Ok I got a little carried away there, sorry :). But my point is: We shouldn't remove the incentive for users to fix their tools or read up on the docs by reducing the impact of their errors or making it easier to work around them. > But ideally this knowledge should be up in gdb too, so that gdb, or > whatever tool is controlling it, can provide more information and > faster response to the user. OpenOCD already gives gdb full knowledge of the target's memory layout (at least what is and isn't flash). /Andreas _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
