|
From: Jeroen N. W. <jn...@xs...> - 2005-07-01 17:47:20
|
Management summary: The purpose of valgrind is to detect problems and errors; although reporting the problems and errors found is the purpose behind this purpose, it is at the same time a necessary evil, on which scarce resources (read programmer man hours) should not be wasted. The introduction in valgrind of the option to produce output in xml also is a proper time to prevent that the burden of supporting multiple platforms is multiplied by the burden of maintaining multiple output modes. In other words: content and presentation must be separated, with valgrind and its tools (for instance memcheck) providing the content, and m_ui performing the presentation. This proof of concept demonstrates that, at least in principle, all code necessary to produce valgrind's output (to perform the presentation) can be generated from an xml file. In this proof of concept, plain text and xml outputs are produced. As an additional benefit, the reference documentation of the output can also be generated. (Not completely supported in this proof of concept.) One limitation, or rather a consequence of the separation of content and presentation, is that the source files generated and the xml files produced are not created for human readability. Tools can be found elsewhere to transform these files into a form suitable for flesh and blood. Small print and disclaimers: This code and documentation generation framework, named MetaDox, is Copyright 2005 Jeroen N. Witmond. I intend to publish this as 'open source', but I have not yet decided on the license to use. Any advice on this subject is welcome. Until then, copies of this work may be used for review and educational purposes only. As this is my first serious application of xml and xslt, corrections and suggestions for improvement on this subject will be especially welcome. This work comes to you without warranty of any kind. Download: When you agree with the restrictions in the small print above, you can download a copy (approx. 80KB) of this work from http://metadox.xs4all.nl/valgrind-xml/m_ui-0.0.1.tar.gz See the bottom of file README.TXT in the tarball for the complete list of the content of file m_ui-0.0.1.tar.gz, grouped by category. (Note that, contrary to its name, the tarball contains both the generator framework MetaDox and the user interface module m_ui's source generated by the framework.) File README.TXT (approx. 15 KB) can be accessed separately at http://metadox.xs4all.nl/valgrind-xml/README.TXT I look forward to your reactions. Jeroen. |
|
From: Nicholas N. <nj...@cs...> - 2005-07-02 16:01:46
|
On Fri, 1 Jul 2005, Jeroen N. Witmond wrote: > In other words: content and presentation must be > separated, with valgrind and its tools (for instance memcheck) > providing the content, and m_ui performing the presentation. > > This proof of concept demonstrates that, at least in principle, all code > necessary to produce valgrind's output (to perform the presentation) can > be generated from an xml file. > > ... > > I look forward to your reactions. I just took a look at this. It seems interesting, but I honestly had a great deal of difficulty understanding it. The README file had a lot of grungy XML details (which I didn't get much out of as I don't know much about XML) but very little in the way of simple high-level explanation of what you are trying to accomplish. I found the language in the README and your email was pretty impenetrable too -- I felt like I had to find the main ideas buried under the words, rather than having the ideas leap off the page into my brain. This may help explain the lack of response from others so far. (Sorry if that sounds harsh, but I really had trouble understanding things due to the language.) Here's my attempt at summarising what you are doing. - You want to separate the content and presentation of the content. The current Valgrind system would be responsible for producing the content in XML format, and the presenter would be a separate program that presents that content in a nice form. - Also, you want to auto-generate the presenters from XML descriptions(?). I've basically just restated the two sentences you wrote that I quoted above, which I found to be the two most informative sentences. As for the code you've written -- what is it supposed to do? Can I build and run a program in there? After reading the docs I had no idea what your package is meant to do. There were lots of low-level details about the XML schemas, but again not enough high-level information. And I tried to build it as per the README: mkdir generated cd generated ../configure --options make target The 'configure' script didn't like the --options flag. I removed that and 'configure' worked, but there was no target called "target" in the Makefile (should that say "make <target>", and if so, what is a suitable target?) So I tried plain "make" and I get build failures: xmllint --noout --schema ../repository.xsd ../sample-repository.xml > repository.validation.stamp Unknown option --schema make: [repository.validation.stamp] Error 1 (ignored) DOMCount -v=always -s -n -f ../sample-repository.xml > repository.validation.stamp || ( rm repository.validation.stamp; exit 2) /bin/sh: DOMCount: command not found make: *** [repository.validation.stamp] Error 2 Maybe my version of xmllint is too old. So enough criticism, now for the good parts. I like the basic idea that I think you're trying to achieve here -- the separation of content and presentation. Currently Valgrind is hard-wired to use a single "presenter", the text-based one, and other tools (eg. GUIs) have to parse that. So, in a sense, the text-based presenter is privileged over all other possible presenters. I'd like to see the text-based presenter separated from the core of Valgrind. We could still distribute the text-based presenter as part of the base distribution, but the more modular architecture would make life easier for other presenters. This raises various questions: - What format should the passed information be in? I had been thinking some kind of structure binary format, but XML may be much better, since it's widely used and is extensible/self-describing. The current XML output is still English-specific, it could certainly be tweaked so that the message strings aren't embedded in the format, or are at least described in enough detail via tags that they can be reconstructed in other languages. - How should the information be passed from Valgrind to the presenters? Would the presenter be a separate process running in parallel with the Valgrind process? How would they communicate -- through a socket, as done with the valgrind-listener program? What about when you use --trace-children=yes and you have multiple Valgrind invocations running -- should they communicate to the same presenter? - How would the presenter process the information? Some kind of incremental parsing would probably be needed. Or you could do it all at the end, but I think it's useful to see errors emitted as soon as they are found, since that gives you information about what point the program was at. (Eg. I press button A and get an addressability error.) - What about output that the presenters shouldn't have to handle, eg. debugging output when you use -v, or abort messages when something goes wrong? Perhaps it's ok for Valgrind to still just print those to stderr. - How would command-line options be handled? Some of the options that are part of Valgrind would become part of the presenter. But we'd want to make it easy for a user to see the presenter options and the Valgrind options together... it might be confusing if you had to do "valgrind -h" separately from "presenter -h". - Suppressions are an interesting case. Everyone dislikes how they are currently generated. Perhaps having a separate "presenter" for them would be useful. Ie. Valgrind would just spit them out, and the suppression-presenter would be responsible for putting them into a file, or asking the user if they want to see it printed on the screen, or whatever -- people could write their own presenters to process suppressions as they want. (One interesting thing is that these separate programs of course wouldn't have to be written in C.) - How to keep this all manageable and robust? We don't want to get over-excited and create an unwieldy system. As for your suggestion of auto-generating the presenters, I'm less convinced currently that this is a good idea. I worry that it will restrict the presenters too much -- it might be good for text-based presenters, but what about eg. GUI front-ends? ---- Anyway, that's my first impressions. I hope it's useful feedback. Please correct anything I've got wrong. N |
|
From: Jeroen N. W. <jn...@xs...> - 2005-07-04 20:20:05
|
Nicolas,
Don't worry about sounding harsh. Your reaction may not have been what
I hoped for or dreamed of, but it was certainly what I needed. I am
very grateful that you took the trouble to try and understand my
prose.
Currently valgrind uses VG_(message) to produce a message for the
user. I want to replace these calls to VG_(message) with calls like:
uix_add_frame_to_stack(eip, fn, obj, dir, srcfile, line). This example
replaces the 'if (VG_(clo_xml))' statement, including the else part,
in VG_(describe_IP) in lines 2374-2445 of file
valgrind/coregrind/m_debuginfo/symtab.c, with some changes in the
preceding lines. (The tweakery with booleans for the availability of
data is replaced by the pointers being zero for unavailable data.) As
you can see, this is not a one on one replacement.
To answer your questions: The information is passed from Valgrind to
m_ui in the format programmers like best, an argument list. How m_ui
presents the information to the user, or to the next interface in the
hierarchy, such as a GUI, is up to the user or that GUI, within m_ui's
capabilities. Valgrind, outside of module m_ui, should be and can be
totally agnostic of the user's quirks.
Module m_ui is part of Valgrind. It consists of a number of object
files. There probably will be one or more object files for each one of
vex, stage1, stage2 and each of the tools, to be linked with
them. Thus m_ui runs in the Valgrind process. It is possible and may
be desirable to link the objects for text output into the executables,
and those for other output modes into shared objects.
Currently, all output is produced as soon as the information is
received by m_ui. (The calls to uix_add_frame_to_stack et al. do not
return before the completion of the output.)
A valgrind-listener should be able to listen to the output of m_ui,
just as it listens to Valgrind now. (Of course, valgrind-listener
should not be aware that Valgrind is using m_ui to do the dirty work.)
Using the current state of m_ui, it should be straighforward to
implement a binary output mode and a listener for that binary output
mode.
You are correct: Valgrind just spits out the content needed for the
generation of suppressions and leaves it to the hierarchy of user
interfaces (eg. m_ui -> some variant of valgrind-listener -> GUI) what
to tell or ask the user and what to write to any file.
There are two sides to GUI front-ends. To read the data, they can use
any of the output modes of m_ui. The other side, the presentation of
the data, is not hardcoded in the GUIs I am familiar with (KDE and
Windows), but described in an XML file. I am confident that at least
skeletons for these files can also be generated.
Your questions seem to suggest that VG_(message) can be called from
different threads. If this is the case, then m_ui needs to be made
thread-safe.
Your question about "output that the presenters shouldn't have to
handle" raises enough issues to merit a discussion of its own. Some of
them are:
- It can be claimed that presenters should be able to handle all
output Valgrind/m_ui produces. If they don't, the information will
be lost. (That's what filtering is about.) Likewise, it can be
claimed that Valgrind should use m_ui for all of its output, not
just for some of it.
- Instead of focussing on when or how the output is produced, we
should consider the intended audience for the output. The following
categories within the audience come to mind:
- The user, debugging his application.
- The valgrind developer, or the advanced user, tracking a hard
problem in the user's application and installation.
- The valgrind developer, debugging his svn copy of Valgrind.
For the latter, printing to stderr is the pragmatic solution. As
these printf-statements probably should not be released in an active
state, you should not have to mess with the repository for it.
The output for the middle category should be handled by m_ui, as it
is part of the released code. This can be handled by a few generic
<message> entries in the repository.
For the first category, the user debugging his application, all
output should be with as much structure as possible. This implies
that each unique piece of output Valgrind may want to send as part
of its normal operations should have a <message> entry in the
repository. A useful presenter should handle all of them.
Abort messages are a special case: For the middle category of the
audience, they should be handled like the debug information, but for
the ordinary user it could be presentated to be passed on as is, for
instance a pregenerated bug report.
This focus on audiences, with related level of structuring and
(non-)handling, will also help keep this all manageable and robust.
- The handling of an output verbosity level, and all other kinds of
filtering, are the province of the user interfaces. If Valgrind
cannot afford to waste cycles on a call m_ui will ignore, it is
possible to add an interface to m_ui, allowing Valgrind to ask if a
specific piece of output is needed / will be used.
I mentioned command line handling, because that is another area that
seems suitable for the generation of all required files (sources,
headers, help texts and help handling, documentation) from a
repository in xml. This can and probably should be one file for all
"option consumers" of Valgrind. I guess that the presenter-specific
options can be handled similarly to the handling of tool-specific
options.
Building should result in the performance of all generation,
compilation, linking, running and testing steps in the
Makefile.am. (This is not necessary, as all output files are in the
tarball as well, but not in a separate directory.) The --options on
the ../configure command was intended as a shorthand for '[add your
options here, e.g. --enable-maintener-mode]'. The 'target' on the make
command is optional, defaults to, and should be, 'all'. I should not
have mentioned it.
Program uitest, built from generated files, uitest-main.c among
others, calls each procedure currently available (exactly once, thus
testing the usability of these procedures. It is run four times: once
for each combination of output mode (text or xml) and verbosity
(default or not). Both xml outputs are validated against the schema
(that is also generated from the xml repository) by programs xmllint
and DOMCount. I should have made configure check for the presence of
these programs before releasing the work.
I hope this sheds some light on the matter.
Jeroen.
|