On Sat, Sep 4, 2010 at 7:31 PM, Peter Stuge <pe...@stuge.se> wrote: > 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.
GDB cannot know that it cannot work. The user has, and must have, the power here. If the user tells gdb to load some data to address 0, gdb must try its best to do so, using the information provided (directly or indirectly) by the user to determine _how_ to do it. I know I would hate if gdb tried to outsmart me by disallowing a load of a not-quite-standard configuration just because it doesn't work in other cases. >> 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? I really don't know since I've never used the offset. It's 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. Under normal circumstances, load is a fire-and-forget command, it just does the right thing. Very usable. >> 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. THE workaround you're talking about is not some universal fix for problems related to linking. It may help in some very specific situation with some link script that's broken in a very specific way. 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? >> 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. It cannot. >> 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. A bit too ambitious goal, don't you think, especially when you consider errors that are not errors in the realm of gdb, but outside of it. It's like a blender that would refuse to mix ingredients that are not normally used together. >> > 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. No, the problem is still in the faulty linker script/build system shipped by Olimex(?). Use a Blinky LED example from another source and the issue is gone. > 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. To me that's just smart enough. gdb should not try to _understand_ what the user wants to do (but fails to specify), it should just do what it's told. > 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. Determining what should go where is a job for the linker, not gdb. If the user fails to correctly specify to the linker what she wants to do, why would she succeed in telling gdb the same thing? > 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. Exactly, which is why no fix belongs to either gdb or 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. How would that help instead of hamper usability? /Andreas _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
