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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison