Some notes on translation

[Frank Ch. Eigler]

Hi -


hunt wrote:

> [...]  My only thought was to reimplement dump_stack() for each
> architecture in the runtime library.  Maybe someone has a better
> idea.

First pick a sensible mapping into the script data types.  Would the
value of dump_stack() be a string containing hex addresses?  Or would
you want to invent a vector-of-ints primitive type?  Or is an
array-lookup syntax suitable instead (as in pc=backtrace[4] for the
fourth level)?

> Supporting that has caused me some real headaches.  I originally
> didn't want to support arbitrary-size strings as hash keys because
> of the memory management problems.  [...]

Let's get a sense whether the logic and track-keeping needed to
support arbitrary sized strings is even needed.  How big strings do
you believe real probe scripts will need to deal with?  Is it really
necessary for them to be growable without limit?  Likewise for other
structures like lookup tables that might conceivably require dynamic
allocation as opposed to static preallocation: is the need real, in
the context of probe scripts?


> [...]  I think I will probably end up adding a malloc lib into the
> runtime.

The mm/mempool.c code may be a close to perfect fit for this.


- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20050225/5114f201/attachment.sig>