|
From: Naba K. <kh...@gm...> - 2005-05-04 06:19:40
|
Hi Nicholas,
On Wed, 2005-05-04 at 07:42, Nicholas Nethercote wrote:
> So what would that look like?
>
Okay, the kind of API we (the IDE developers) would generally prefer is
a sort of async updates from valgrind library while it executes the
process under scrutiny. There needs to be additional API to meaningfully
interpret the delivered data.
Now, I know little about the kind of data valgrind reports, but as an
example let's take the memory corruption/leak reports which are usually
accompanied by stack snapshots. Here is a rough sketch of such an API.
/* We begin by invoking valgrind to run the process: */
int valgrind_execute (update_callback, options, additional info ..);
/* The IDE updates its UI based on the callback. */
void
update_callback (ValgrindRecord *r, other info ...)
{
switch valgrind_record_get_type (r)
{
case VALGRIND_RECORD_MEMLEAK:
... update mem leak report ...
case VALGRIND_RECORD_MEMCORRUPT:
... update mem corruption report ...
}
}
/* Record functions */
ValgrindStackTrace* st = valgrind_record_get_stack(ValgrindRecord *r);
... Other functions to retrieve record information ...
/* Stack functions */
int valgrind_stack_get_length(ValgrindRecord *r);
ValgrindFrame* sf = valgrind_stack_get_frame(ValgrindRecord *r, int
index);
... Other stack and frame operations ...
Well, that was overly simplified view of the API in a language that I am
used to, but I hope you get the point.
I understand that valgrind could not be operated in the same process
space as the main program and hence the difficulty in making it a
library. It's one unfortunate situation that I hope you people could
come around :).
>
> Here's how I imagine the KDevelop plug-in works: you invoke Valgrind
> somehow, and KDevelop works out what options to pass to Valgrind,
> then runs Valgrind (and the user program under it), then collects
> the output somehow, parses it, and presents it to the programmer
> in the IDE somehow.
>
There is nothing wrong in doing it the hard way, except that every IDE
would be implementing it (which is a waste to begin with) and all of
them would be struggling to maintain their parsers. Ask any developer
who has maintained such CLI output (meant for human readability) parsers
for a reasonable time how much fun it is.
The whole point of the suggestion is to make life easier for the IDE
developers at the cost of offering some helpful API from valgrind. Even
if full blown library interface is not feasible, as I mentioned earlier,
having some sort of predictable and machine-readable output from
valgrind would still be useful.
Thanks.
Regards,
-Naba
|