This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |