On Fri, Jan 30, 2015 at 10:56 AM, Matthias Meier <[email protected]>
wrote:
> Hi Andreas
>
> because I got no response from you...
>
Sorry, I'm just a bit busy. Please keep the list in CC so that someone else
may respond instead.
> I would like to ask you again if you agree that 'uxTopReadyPriority' is
> not the correct way (because its value is to big and thus copies garbage
> which gdb uses as task pointers thereafter)?
>
> Sorry perhaps I explained it unclear and/or I annoyed (?)
>
No problem, I understand. However I'm not the author of that patch and I
have hardly used FreeRTOS and only once did I test OpenOCD RTOS support. So
I'm not the right person to determine if this is the correct solution or
not.
Unfortunately the original author (also the author of the generic RTOS
support) does not reply to comments on Gerrit.
However I suspect that uxTopReadyPriority will only contain garbage if
FreeRTOS hasn't been initialized yet, i.e. when you just powered up the
target and loaded the code with GDB and halted at the reset vector/start of
main. I think the same problem will exist for the other data structures
too, even if you use the static configMAX_PRIORITIES. The lists themselves
will contain garbage and may fool OpenOCD into making up false task
contexts.
IIUC OpenOCD reads out the values every time GDB asks for thread info so
any problems due to garbage values will self heal after they're initialized.
>
> I agree with you that my solution is not very nice because (at least if
> FreeRTOS source is changed it is not guaranteed that xDelayedTaskList1 will
> be allocated directly after pxReadyTasksLists).
>
To be clear, unless I'm mistaken it's never guaranteed which order in
memory the compiler/linker will allocate objects, even if they are adjacent
in source code (compiler specific switches may enforce order though). So
that solution is a no-go.
> Better would be to get directly the arraysize of pxReadyTasksLists
> somehow.
>
> The size of variables (as pxReadyTasksLists) seems not to be in the symbol
> table, arn't they?
>
> But perhaps openocd could ask the arraysize of pxReadyTasksLists from GDB.
> (At least GDB knows this size by entering the command 'disp
> pxReadyTasksLists').
>
Unfortunately, as far as I know, GDB only offers to look up symbols, not
generic expressions.
>
> if it is too complicate I propose to let it as it was (without any patch)
> so one could define the missing variable outside in the FreeRTOS project by
> defining:
>
> char uxTopUsedPriority=configMAX_PRIORITIES;
>
>
This is what http://openocd.zylin.com/2347 does. But it would be better if
the code didn't have to be instrumented.
/Andreas
> -------- Weitergeleitete Nachricht -------- Betreff: Re: [OpenOCD-devel]
> [PATCH] support for recent FreeRTOS releases without uxTopUsedPriority
> variable Datum: Tue, 27 Jan 2015 18:14:01 +0100 Von: Matthias Meier
> <[email protected]> <[email protected]> An: Andreas
> Fritiofson
>
>
> >
> > The symbol the patch is using is uxTopReadyPriority,
> > not pxReadyTasksLists. I'm not sure what you're trying to show here.
> ok sorry you are right, I apologize...
> >
> >
> > My interpretation of uxTopReadyPriority is that it is the highest
> > priority list that can contain a task. Ready lists above that priority
> > need not be checked as they are empty.
>
> I checked this again with my FreeRTOS project with configMAX_PRIORITIES
> set to 5 ...
>
> When I start OpenOCD I get a value of 10 for uxTopReadyPriority (read in
> <OPENOCD_SRC>/src/rtos/FreeRTOS.c with your patch).
>
> But more is not better: in <OPENOCD_SRC>/src/rtos/FreeRTOS.c with this
> there are uxTopReadyPriority=10 array elements copied from the FreeRTOS
> pxReadyTasksLists[] whereas this list has only a size of
> [configMAX_PRIORITIES] elements. So you read garbage behind the end.
>
>
>
>
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
