-1

I have generated a parser code using Lemon Parser. I am not able to debug the generated code. Control shows some other source code than the currently executing statement. Breakpoints are displaced. I tried on gdb and Visual C++. Both have the same problem. Please tell me the way to debug it.

Artem Zankovich
  • 2,319
  • 20
  • 36
Bharadwaj
  • 1,071
  • 2
  • 8
  • 8
  • Did you compile with debug information? – crashmstr Jun 30 '11 at 12:18
  • Yes I did.. I have a file which contains main program. That is debugging fine. Stepping in and stepping thru as well as Break points are all working. The moment the code enters the parser generated code, control(cursor) will point somewhere else and execution will be happening somewhere else. Now I am debugging with printfs. Its very tedious job. At times I put BP for function then I see the call stack for the flow of the code. – Bharadwaj Jul 01 '11 at 04:16
  • I've only seen that kind of behavior when either: release build or build with optimization turned on, or the build is not up to date. – crashmstr Jul 01 '11 at 12:09

3 Answers3

2

Let's say your input file is named mylexer.y in which case Lemon will generate myparser.c and myparser.h

Inside of myparser.c you will see lines such as this

#line 1 "myparser.y"

These are line directives. They are good for tracing syntax errors back to the file that was used to generate the code. They are not good for debugging.

To suppress them invoke Lemon with the -l option.

lemon -l myparser.y

To see other options not mentioned in the documentation use -?

lemon -?
kfields
  • 56
  • 1
  • 4
1

The following is a certified WAG (Wild Ass Guess):

I would recommend looking at all of the macros being used by the parser generator and see if there are any escaped newlines in them. If there are, try removing all of them (by joining the lines together) and then recompile the file. Then looked at the code in the debugger -- things suddenly may be back to where they should be.

Backstory: Back in the 80's I developed and marketed a debugger called CDB. As I ported it to anything that had U*NX in it's name I became intimately familiar with the idiosyncrasies of the various compilers and how they emitted debug info in certain situations.

One widespread problem had to do with macros that had escaped newlines them. E.g.

#define foo(bar) bar + \
    snort + something_else

x = foo(5);
y = 2;

If the line number for y = 2; should have been 5, many symbol tables would end up showing it as 6, and every line after it would be off-by-one. And each use of such a macro would throw the line numbers farther and farther off.

Peter Rowell
  • 17,605
  • 2
  • 49
  • 65
0

Check optimization, debug information options if you are building them as lib/dll.

xijing dai
  • 317
  • 1
  • 5
  • 14