On Tue, Sep 6, 2011 at 2:24 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Mon, Sep 05, 2011 at 07:45:36PM +0000, Blue Swirl wrote: >> On Mon, Sep 5, 2011 at 3:37 PM, Stefan Hajnoczi >> <stefa...@linux.vnet.ibm.com> wrote: >> > String arguments are useful for producing human-readable traces without >> > post-processing (e.g. stderr backend). Although the simple backend >> > cannot handles strings all others can. Strings should be allowed and >> > the simple backend can be extended to support them. >> >> I don't think this is possible in general. Yes if the string can be >> found in the executable (assuming address space randomizations don't >> make that impossible post run), but not if the string happens to be >> constructed in the stack or in the data segment during run time. >> >> So I'd still at least strongly discourage string use. > > I don't like strings either because they introduce variable-length data > that can be expensive to fetch.
This is still a valid point to discourage their use albeit not so strongly. > But it's perfectly doable: stderr and > ust are in-process tracers that have easy access to the string no matter > where it is located in memory. In SystemTap you only have the char* > argument but can use the userspace string copy-in function to fetch the > actual string (again, no matter where it lives in the process' address > space). > > If your primary trace backend is stderr or ust it makes sense to use > them. If you use SystemTap or simpletrace where it is relatively easy > to do post-processing, then it's lighter weight and nicer (IMO) to > record just the address and leave pretty-printing to a post-processing > step. > > We can add string support to simpletrace by creating a new file format > version (or moving to a standarized trace file format). The format > needs to support variable-length trace records, which the current format > cannot support. Then tracetool can detect char* type arguments and add > strcpy code into the generated trace_*(). > > Anyway, tracing should be an aid to developers and users. It should > make USB development easier for Gerd. We need to compete with fprintf > here :). It was pretty easy to avoid most uses of strings for those DPRINTF conversions that I have made. The benefits of tracing aren't in the replacement process (or even development ease), but actual use of the trace points. There fprintf can't compete. > I don't think there is a technical reason why strings are not possible, > it turns out only simpletrace can't do them and that's my fault. Nobody came up with a better design at that time, so it was the state of the art. Maybe it still is since you plan to improve it instead of scrapping.
