Andreas Fritiofson wrote: > 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.
Thanks! Sorry I'm a bit of a gdb noob. I've never used it in-depth in spite of using it a little, over lots of years. > 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 and do something more useful (error message, whatever) than trying to send stuff to OpenOCD *even though* it can not work. > Yes, you can fix the error by telling gdb to load the image with > an offset. What happens then, exactly? Does gdb relocate all sections or does it just send a single offset parameter to OpenOCD? > That won't change the fact that the image is not linked correctly Agreed. > and gdb can hardly be blamed for providing the possibility of a > workaround. If anything I'm blaming gdb for not being smarter about when to automatically add the workaround - or at the *very least* providing relevant and useful error messages. > Nor is it an OpenOCD problem. .. > We can't guess the user's intentions And we shouldn't. > 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. There is not enough information for OpenOCD to accurately determine if it is an error or not. Remember that is very different from "there is no error." Even in gdb there may not be enough information, since the load command is so generic. > "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. A message similar to this would be a significant and real improvement if it could be generated with zero false positives. > Do you want me to try to fix the script for you?" Silly. At most, whoever is generating the error (gdb IMO) could at this point list known memory areas. > That would be neat. Why not take it a step further? .. > 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. Let me make another point, which I think is partially parallell partially orthogonal: There should be adequate error messages for all error cases. All error cases must be detected without heuristics and without ambiguity. > > But ideally this knowledge should be up in gdb too, > > OpenOCD already gives gdb full knowledge of the target's memory > layout (at least what is and isn't flash). Good stuff. The problem is all in gdb then. Freddie Chopin wrote: > Both OpenOCD and GDB work perfectly well with correct files > (standard OpenOCD .cfgs, correctly linked .elf file) so I really > don't see any problem you're trying to fix... Usability. See the point I make above about accurately detecting every error case, and providing users with relevant error messages and ideally suggestions for fixes. It seems to me that the problem is fundamentally the load command, since it does not know what the user wants to do, beyond "send to hardware" - to me that's just too dumb for modern hardware. Sometimes a user *only* wants to load into RAM, other times she *only* wants to load into flash, but without any way to specify that intent in the gdb load command the sections can't be relied upon to detect what is actually a very simple error condition for the user. It does not matter the least that the error is outside gdb/OpenOCD and actually in the linking process if we can reliably detect it. I don't think we can do that at the moment. Neither in gdb nor OpenOCD. The only quick fix would be to always require an offset to be specified in the gdb load command, and error if it does not match the linking. I'm not sure if that's a great idea but it seems intuitive. The load command would no longer be target agnostic (maybe that's a good thing?) but at least it would still be file agnostic. //Peter _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
