Re: can i rewrite yyparse() based on ACTION and GOTO tables extracted from XML output?

[elite liu]

Dear Akim,

        I am writing a utility that convert a table-driven dfa into
condition/if-else form, for example:

/***************************************************************************************/
enum State {
S0,
S1,
S2,
S3,
S4,
S5,
S6,
ERR
};
State state_trans(State s, char input) {
State ret = ERR;
switch(s) {
case S0: {
if (input == 'a') {
ret = S1;
}
else if (input == 'b') {
ret = S2;
}
else if (input == 'c') {
ret = S6;
}
else if (input == 'd') {
;
}
break;
}
case S1: {
if (input == 'a') {
ret = S6;
}
else if (input == 'b') {
ret = S5;
}
else if (input == 'c') {
ret = S4;
}
else if (input == 'd') {
ret = S1;
}
break;
}
case S2: {
if (input == 'a') {
ret = S3;
}
else if (input == 'b') {
ret = S4;
}
else if (input == 'c') {
ret = S5;
}
else if (input == 'd') {
ret = S4;
}
break;
}
case S3: {
if (input == 'a') {
ret = S4;
}
else if (input == 'b') {
ret = S3;
}
else if (input == 'c') {
ret = S5;
}
else if (input == 'd') {
ret = S1;
}
break;
}
case S4: {
if (input == 'a') {
ret = S2;
}
else if (input == 'b') {
ret = S4;
}
else if (input == 'c') {
ret = S5;
}
else if (input == 'd') {
ret = S4;
}
break;
}
case S5: {
if (input == 'a') {
ret = S0;
}
else if (input == 'b') {
ret = S2;
}
else if (input == 'c') {
ret = S4;
}
else if (input == 'd') {
ret = S6;
}
break;
}
case S6: {
if (input == 'a') {
ret = S1;
}
else if (input == 'b') {
ret = S3;
}
else if (input == 'c') {
ret = S5;
}
else if (input == 'd') {
ret = S4;
}
break;
}
case ERR:
break;
}
return ret;
}
/***************************************************************************************/

If above codes are writen in tabled-driven implementation, it should be
more concise.
I convert table-driven implementation into state and lookahead judgement
form, because i want to capture FSM coverage.
A simple walkaround is making use of AFL (an edge coverage monitor tool
which based on branch instrumentation):

afl-clang-fast -c test.cpp [+] Instrumented 57 locations (non-hardened
mode, ratio 100%).

For example, it's difficult to instrument mysql DBMS because of 4.5 Million
of source codes. It will run several days to cover maximum edge coverage.
However, it's quite easy to capture the parse state FSM coverage based on
this approach.

I will implement it after three or four work days. Regards,
Levin

Akim Demaille <akim@lrde.epita.fr> 于2021年10月20日周三 下午12:01写道：

> Hi Levin,
>
> > Le 14 oct. 2021 à 12:30, elite liu <eligere.liu@gmail.com> a écrit :
> >
> > Hi Guys:
> >
> > Because of customization necessaries, i want to rewrite yyparse() based
> on
> > ACTION and GOTO tables -- a more straightforward way, just like the
> classic
> > compiler book does, and ignore error recovery.
> > bison is more complex due to efficient consideration.
>
> Could you be more specific about what you'd like to change?  Also,
> what's the problem with error recovery?  It should not come in your
> way, it's fairly independent.
>
>
> > I notice  bison can dump XML-format output. In XML output file, symbols
> > both terminals and nonterminals, rules are record.  shifts, reduce , and
> > goto actions, conflicts are fully listed.
> > But i don't know whether the information are complete enough to create a
> > big ACTION table and GOTO table based on xml extraction, where conflicts
> > are solved like precedence,  %nonassoc, and %right and %prec can be well
> > treated from the table guided actions.  I try to store ACTION table and
> > GOTO table using std::map. Efficiency is not a focus.
>
> I very much doubt that it's enough to build a parser, and I have no
> intention
> to make it complete enough to this end.  The point of xml output is only
> helping the (human) user to understand the parser.  It's just a structured
> y.output.
>
> However Bison features "skeletons": the backend are written in m4, failry
> independent from the bison executable.  Have a look at
> data/skeletons/yacc.c
> for instance.
>
> Cheers.