> On 17 Mar 2017, at 12:56, Freddie Chopin <[email protected]> wrote:
>
> .. If we are only discussing some abstract idea,
> then let me say that the idea is great and I would love to see that
> implemented.
:-)
> I just don't know how do you plan to solve all these incompatibilities
> that I've mentioned. If you plan to somehow solve them (and have some
> viable solution), then this is an interesting thing.
sure, dīvide et īmpera, one at a time.
> But if you don't,
> and expect the RTOS to adhere to the DRTM structure that you used for
> your own project, then I'm afraid that it's not very tempting (unless a
> particular RTOS uses almost 100% identical core concepts)...
no, obviously this is not an option.
I'll start with µOS++ and add the necessary support for existing internal
objects.
than I planned to add support for FreeRTOS, less from a necessity but more as
an exercise.
> This could be easily done with run-time support, but with in-RAM
> buffers for the threads where the RTOS would just fill the info exactly
> as needed by GDB (thread address + string). This would be extremely
> easy to support in OpenOCD and probably easy to implement in the RTOS,
> but would use some RAM and - unfortunately - cause some run-time
> overhead, possibly significant.
I'm not sure I can follow you, but this sounds very complicated.
> I think that if we would agree on some
> structure of that data (for example standard circular doubly-linked
> list) and its contents (described as offset + size, with some sentinel
> value meaning that this is not implemented, like 0 size), then this
> would be much easier, but still cause some overhead at run-time, only
> smaller (so maybe acceptable). It would still use more RAM than the
> native approach.
my plan is to use rom, not ram, which usually is not as limited, so a few tens
of bytes used for the metadata would be perfectly acceptable.
the current metadata looks like this:
const __attribute__ ((section(".drtm")))
struct os::rtos::port::drtm_s os_rtos_drtm =
{
{ 'D', 'R', 'T', 'M'},
{ 'v', OS_RTOS_DRTM_VERSION_MAJOR, OS_RTOS_DRTM_VERSION_MINOR,
OS_RTOS_DRTM_VERSION_PATCH}, /**/
&os::rtos::scheduler::is_started_, /**/
&os::rtos::scheduler::top_threads_list_, /**/
&os::rtos::scheduler::current_thread_, /**/
offsetof(os::rtos::thread, name_),
offsetof(os::rtos::thread, parent_), /**/
offsetof(os::rtos::thread, child_links_), /**/
offsetof(os::rtos::thread, children_), /**/
offsetof(os::rtos::thread, state_), /**/
offsetof(os::rtos::thread, context_.port_.stack_ptr), /**/
offsetof(os::rtos::thread, prio_assigned_), /**/
offsetof(os::rtos::thread, prio_inherited_)
};
that's not such a big deal.
> I really see no way of providing all that descriptions in compile-time
> in a generic way. Let me reiterate, that the idea is interesting, but
> the problems are quite significant.
version 0.x is experimental and µOS++ only, intended more as a proof of concept.
for version 1.x, I plan to define the metadata in what I call "Compile Time
Binary JSON" (yes, I know, another standard...).
there are many binary JSON implementations, but, as far as I know, all are
intended to serialise at run time.
our goal is to encode offsets and actual pointers, with their native
endianness, prefixed with some numeric ids and packed tightly in a structure.
I'm pretty sure that o solution can be imagined to do this at compile time,
with a bunch of macros in C or templates in C++.
> For start, just ignore everything
> else and tell me how would you describe iterating over threads in your
> system (tree-like arrangement of lists with parent-child relationship)
> and the system which uses just a single flat list.
let's see what we need to describe the tree-like arrangement:
- a type that says 'intrusive list'
- address where the head element is (a list element is a structure with 2
pointers, prev and next, pointing to other such elements, in a circular way,
with the empty list having only the head element with links to itself)
- offset of next and prev in the list element (basically this tells which is
first, next or prev, but it is easier to generate offsets at compile time, and
anyway when accessing the pointers it is also easy to add offsets)
- offset of the intrusive list element in the TCB (the µOS++ implementation of
intrusive lists is inspired by your implementation in distortos, list elements
are stored in the TCB, point to each other, and to get the TCB address an
offset needs to be subtracted from the element address)
- offset of the children list element in the TCB (each thread keeps track of
the threads it created in a separate list, identical to the top level list.
- optionally offset to the parent pointer,
{
...
"threads":
{
"type": "intrusive-list-tree",
"element":
{
"offset_of_prev": 0,
"offset_of_next": 4
},
"address_of_top": "0x20001234",
"tcb":
{
"offset_of_element": 24,
"offset_of_children": 28,
"offset_of_parent": 32
}
},
...
}
the "element" and "tcb" objects are just for grouping.
in my opinion, I doubt there is any such structure used in existing RTOSes that
cannot be represented in a JSON in a similar manner.
for a single flat list, if it is still intrusive, I would use a similar
definition, without the "offset_of_children" and "offset_of_parent". the
implementation of the "intrusive-list-tree" might very well handle the flat
version too, if those offsets are missing or 0.
---
since this is no longer an OpenOCD issue, I copied this last messages to the
GNU ARM Eclipse forum:
https://www.element14.com/community/message/218654/l/drtm-debug-run-time-metadata-proposal#218654
I would appreciate your contributions to the DRTM proposal as comments to that
post.
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
