semantic error: cannot expand unknown type

David Smith dsmith@redhat.com
Mon May 15 17:20:00 GMT 2006


On Fri, 2006-05-12 at 18:43 -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> dsmith wrote:
> 
> > [...]  Yeah, it is a bit ugly.  However, if we don't explicitly only
> > take "return" and "function" here, then the user is free to write
> > 'probe kernel.while("sys_read").if'.
> 
> I'd be OK with that.  We can keep a separate namespace for probe
> points.

OK.  I've allowed all keywords there.

> > [...]
> > >We should outlaw the latter two (and rename or remove the current
> > >string() function in conversions.stp).
> > >
> > Glad we agree.  What do we want to rename the string() function to?  
> > ltoa()? long2str()? long_to_string()?  Or something else?  I'd probably 
> > pick "long_to_string()".
> 
> Or just remove it altogether: sprint(<numeric-expression>) is equivalent.

True.  What about the hexstring() function in conversions.stp (which
also calls sprintf)?

> 
> > [...]
> > if (!(ok)) return (value) = (retval())
> > When the parser sees the return, it isn't smart enough to realize that a 
> > return keyword isn't valid in a probe point, only in a function.
> 
> Yes, and similarly with "next".  Detecting the wrong "escape"
> statement is left to translation time.  One could fix the parser in a
> couple of little ways:
> - parametrize the statement parsers, passing along a "in_function_p" flag
>   that originates from from parse_functiondecl() and parse_probe()
> - or pass the equivalent flag within a parser class member variable
> - or fork the parse_stmt_block and parse_statement
> 
> The first and second of these seem okay, only slightly noxious.
> The third has a theorist's respect and an engineer's disdain.  :-)
> 
> - FChE

I took the second route.  See the attached patch.

-- 
David Smith
dsmith@redhat.com
Red Hat, Inc.
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: parse.cxx-patch
Type: text/x-patch
Size: 12021 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20060515/65d68f66/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parse.h-patch
Type: text/x-patch
Size: 803 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20060515/65d68f66/attachment-0001.bin>


More information about the Systemtap mailing list