[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RTEMS dynamic task loading and stack size analysis
- Date: Wed, 08 Sep 1999 15:34:50 +0000
- From: charles.gauthier at iit.nrc.ca (Charles-Antoine Gauthier)
- Subject: RTEMS dynamic task loading and stack size analysis
I already sent a second post about using link maps. I only thought about
it later. What you describe sounds like what I had in mind, except that
I had not considered dynamic code relocation at load time.
I would not bet that code may be relocated at load time in all cases, at
least not easily. In our experience, many compilers/linkers produce code
with absolute addresses, and you may not get the necessary info at load
time to relocate the code. It depends on the tool suite, the target
image format, and the compile/link time flags. Many Unix tool suites
expected to produce executables that ran at fixed virtual addressesses;
there was no need for a relocating loader.
I don't know off-hand what can be done with gcc/ld for individual image
formats and target processors. I assume that this must be investigated
on a case by case basis.
P.S. What about your stack analyzer tool. It would be a fantastic
addition to RTEMS. We also had one for m68k. Perhaps we should revive it
and even try to port it to other architectures.
Our stack analyzer basically computed the stack requirements of every
function. It would be run on the OS first with a list of functions to
"trace" as input. The result of the run is a file that contains the
stack requirements of every OS function. Information about exeception
stack requirements was also computed (the exeception handlers are
specified in the input file). The tool is then run on applications with
the produced file as input, and with a list of task entry points. The
result was a list of stack space requirement for every task, with and
without exception processing. With this tool, you did not have to do a
full analysis of an image. Furthermore, it was possible to split the OS
and the applications. For example, the OS may have been in ROM, and the
apps in RAM. When the apps were linked, they did not include the OS
(this is were the link maps were used to resolve calls to the OS). The
drawbacks of the tool are that it did not have any intelligence when it
encountered function calls through pointers. For every function pointer,
the user had to specify which function was expected to be called. This
would be a real drag with C++ virtual functions! The tool would detect
recursion and ask the user how many recursive calls should be assumed.
Mike Moore wrote:
> Subject: RTEMS dynamic task loading
> My name is Mike Moore, and I work for ITT in Rome NY. I received
> a forwarded copy of your call for ideas on dynamic loading in RTEMS.
> I do it all the time. I created a relocator that can take a gdb file and relocate it to
> any address. I also created a service for communicating with RTEMS tasks, but the
> downside is that it uses a custom, home brew messageing system. There is nothing majic
> about this messaging system, and it could be replaced easily with RTEMS native messaging.
> Here is how it works. The "controller" service decides to load a task (usually because
> some other task decides it wants to load a new task) and it sends a message to the
> target processor to allocate memory for the task. The target processor responds with
> the address of the space allocated. Next, the controller relocates the gdb file
> to the allocated address and sends it to the targetprocessor, using the new space to put it in.
> After this transfer, a message is sent to the target processor to create and start
> the new task.
> The relocator is also used to calculate the size of the gdb file, which, by the way, may have
> its own static storage area. Stack size (in our case we prohibit application tasks loaded in
> this way from using malloc, and recursion) is computed by another home brew tool by
> following all calls and adding up all frame sizes. We are memory constrained, so in our case we
> need to do this stack stuff. Otherwise, you can just use a default stack size and hope
> for the best.
> The new task can make use of any functions already resident on the target processor - actually I
> implemented only a linking to statically loaded stuff, but I don't think
> linking to other dynamically loaded stuff is a big trick. The way this works is that I
> collect addresses of resident stuff from their link maps, and just link it into the new task.
> Dynamically loaded tasks can, of course, be terminated and deallocated.
> The controller service runs on one processor, and can load tasks into any processor.
> Bad news: I wrote this for a customer, and can't just automatically release it.
> Special software that makes all this work:
> the "controller"
> the relocator
> a resident task on each processor that handles management of new tasks
> A little tool which gathers addresses from a map, and makes it understandable to the linker
> a stack size analyzer tool.
> Good luck!
Software Engineering Group
Institute for Information Technology
National Research Council of Canada
Ottawa, ON, Canada