On Fri, Feb 16, 2001 at 04:00:05PM -0500, Sam Tregar wrote:
> I think he meant that using a symbolic debugger is hard, not that it
> wouldn't work. After all, when GDB is tell you that:
> (*fooz).blazt[10].mark[0]->set(fungle(10));
> Is causing a seg fault and all you wrote was:
> $fooz->set(10);
> You've got to get pretty smart to figure out what's going south.
Oh, I see what you mean. Yeah, my use of the word "macro" was misleading
there. I'm thinking more of "template".
Very, very, very rough example so you get the idea:
vtable.spec could have something like
void add normal_method # Where normal_method means a, b, and a key.
IV left = a->get_int();
IV right = b->get_int();
/* handle overflows */
a->set_int(left + right);
#if ($Config{memcpy}... || some Perl expression...)
memcpy(foo, bar);
#else
my_memcpy(foo,bar);
#endif
producing
void add (PMC* a, PMC* b, void* key) {
IV left = a->get_int();
IV right = b->get_int();
/* handle overflows */
a->set_int(left + right);
memcpy(foo,bar);
}
which is not so bad to handle in a symbolic debugger.
The real benefit would be that the Perl program would know about all the
methods and be able to automatically construct the vtable definitions and
the relevant enum's, and that all the system-specific crap wouldn't show up in
the generated C files, so they'd actually be *easier* to handle.
Simon
--
Pretty, smart, sane: Pick two.
- Ron Echeverri
