> On 17 Mar 2017, at 14:57, Andreas Fritiofson <[email protected]> > wrote: > > ... Just a tip, another even better option is to not use any target memory at > all. ... OpenOCD has access, via GDB, to all the symbols in the debugged > binary.
right, this would be a more efficient option, both in terms of memory and speed. I have some comments on this solution: - in addition to a few offsets, a generic solution might also need to pass offsets for all registers in the stack context, for both cases, with and without FP; although possible, this would require quite a lot of symbols - other data that might need to be passed, are small dictionaries, like one to represent legal status codes and their string names; similarly, although possible, this would require quite a lot of symbols - speed shouldn't be a big problem, these offsets are retrieved only once, during initialisation generally speaking, your solution would require to transform a hierarchic structure like a JSON into a linear list of name=value properties, restricted to integer values. I guess it can be done, but passing arrays would be more tricky, since a symbol with the number of elements must be passed first, then update the list of symbols with a number of entries, one for each array element. I don't know the code in OpenOCD, but generally, any GDB server cannot simply fetch the symbols, it should provide a list of names and the GDB client will provide the values when it wants. --- another possible solution would be to use a separate elf section, not loaded into memory, similar to those used for the debug info. this would not have any memory constraints, but would require some support from the GDB server (OpenOCD or other) to access these sections known directly only by the GDB client, which probably is not that easy. regards, Liviu ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
