On March 22, 2018 4:20:22 AM PDT, Vlad Ivanov <vlad.iva...@lab-systems.ru>
wrote:
>Having a way to read that from a config file would be nice, and
>eventually
>other RTOS could use such mechanism too. Now, openocd uses TCL a lot
>and
>it seems that it would meak sense to read it from a TCL file too.
>I was thinking syntax like this:
>
>rtos add_target freertos [ dict create \
> { target_name } { AA2883XLPQ } \
> { thread_count_width } { 4 } \
> { pointer_width } { 4 } \
> ... \
>]
>
>Thoughts?Yes please! If I may make a suggestion, however: I am not sure what you planned to put in the rest of the dictionary, but I can see two ways that the stack frame decoding could potentially work: 1. TCL defines a layout, indicating at what offset from the stack pointer each register appears. This layout data is passed into C and used to decode stack frames. 2. TCL defines a proc. When C needs a thread’s registers, it calls the proc. The proc does whatever it needs to (probably lots of mem2array calls) and then returns the registers to C in some way (perhaps returns a dictionary or something). I would really like to see #2. It has the advantage that different threads can have different stack frame layouts (e.g., some threads have floating point registers and some don’t, some have some memory protection data saved on the stack and others don’t, or whatever more complex examples you care to make up), and only TCL, not C, needs to change to accommodate such things. It could even handle ports that don’t store their registers on the stack at all, but rather in something vaguely like a traditional x86 TSS! Taking this even further, what if the business of enumerating threads were also done by TCL? It would shorten the development cycle of ports to new RTOSs as well as just new ports. I don’t suspect that any of this work is so performance-critical that using TCL would slow it down top much. -- Christopher Head
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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 OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
