wow, I don't know. You must be clear on something here. Are you planning
to debug the compiler or the generated DLL ?
My idea of events is that you have a grammar for that script language. Now
you write a compiler to parse source code written in that language and
generate a DLL . Is this correct? or does the compiler itself become the
DLL ?
In the later case, if the compiler itself is a DLL and your debugger is
working on it, it will find the lines in your grammar file (parse-script.ysay)
for the script language. (NOT the source lines of the script file and
NOT the souce lines in the generated parse-script.tab.c file)
Supposing thats not the case. Then the scenario is same as any other
compiler. The gcc compiler compiles C source code to an executable file. If
you compile for use with gdb (with -g option), you can attach gdb to the
executable. Your case must not be too different, except you generate a DLL
instead of an executable.
The question then is how that works (i.e how exaclty the -g option works).
How do you compile source code for use with a debugger ? I don't know. You
are better off asking this question on comp.compilers as suggested by
Hans. This has nothing to do with Bison again.
satya.
On 1/11/07, Sandon Racowsky <address@hidden> wrote:
>
> So if I'm understanding you correctly, I need create something along the
> lines of a C macro that appends line numbers around blocks of bison actions
> while simultaneously creating my own debugging profile db, so that when I
> encounter the C line numbers, I can reference the original source by doing a
> quick lookup in the db?
>
> On 1/11/07, Satya < address@hidden> wrote:
> >
> > oooh.. complicated situation :) The bison generated C parser uses
> > #line compiler directives to point to the line in the .y file while
> > debugging. i.e., if you have a file like grammar.y and generate
> > grammar.tab.c using bison, and try to debug grammar.tab.c, the
> > debugger can point to corresponding lines in grammar.y while you
> > single step.
> >
> > what you are doing is grammar. y ==> grammar.tab.c ==> add some more
> > files ==> compiler for your custom script language that generates DLLs. You
> > have to figure out a way to embed line number and file name information in
> > your DLL such that when it is debugged, the debugger has sufficient
> > knowledge to point back to the lines in script file. How to do that -- i
> > know not. Also, it has nothing to do with bison.
> >
> > satya.
> >
> > On 1/11/07, Hans Aberg <address@hidden > wrote:
> > >
> > > On 11 Jan 2007, at 19:44, Jachyra wrote:
> > >
> > > > If I use bison to essentially parse my
> > > > language and generate C code (which gets compiled to a windows
> > > > binary), and
> > > > then create a debugger that attaches to the DLL that was compiled
> > > > in debug
> > > > mode (for the sake of argument, lets say I'm just using dbg), will
> > > the
> > > > debugging information I get from the debugger refer to the lines
> > > > and symbols
> > > > in the code that was written in my custom language, or will it be
> > > > reffering
> > > > to lines and symbols that are in the bison generated "C" code?
> > >
> > > Currently, you only get to debug the parser C-code, and will have to
> > > use to special techniques to debug the parser itself. But Satya is
> > > working on a debugger format for the parser itself, so that one can
> > > follow the position in the .y file. But this may not what you are
> > > asking for - your project probably asks fro a debugger for the
> > > compiler of the language you are implementing. If you do not get moe
> > >
> > > info in this mailing list, you might try the Usenet newsgroup
> > > comp.compilers, and its FAQ, posted there monthly.
> > >
> > > Hans Aberg
> > >
> > >
> > >
> >
> >
> > --
> > Work expands to fill the time available for its completion
> > (Parkinson's law).
> > http://cs.uic.edu/~spopuri <http://cs.uic.edu/%7Espopuri>
>
>
>
--
Work expands to fill the time available for its completion (Parkinson's
law).
http://cs.uic.edu/~spopuri <http://cs.uic.edu/%7Espopuri>