Home > Archive > Compilers > October 2007 > Requirements from ASTs by Debuggers and Source Browsers
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Requirements from ASTs by Debuggers and Source Browsers
|
|
| parthaspanda22@gmail.com 2007-10-26, 10:16 pm |
| I am trying to understand what requirements are expected from ASTs by
Debuggers and Source Browsers.
I understand that bison provides support for --locations which can act
as a base on which to build extensive source context information.
How do we build upon that base? I have a vague memory of extensive
source correspondence support in the EDG IL. Unfortunately, I dont own
a copy so I have to rely upon memory which isnt much.
I dont think gcc supports source browsing, so are there any other
reasonably complete implementations in the public domain that can
provide an exhaustive view of things that source browsers and
debuggers expect from a FE including and in addition to locations?
I have heard of the phrase "automated tree construction". What exactly
do they accomplish? I admit, expecting automation for my problem is
probably too much, but I take the risk of asking about it.
Sincerely,
Partha Sarathi Panda
[I told him that I've never seen a debugger that uses an AST. They
tend to use a symbol table and a map of source lines to object code
locations. -John]
| |
| IndianTechie 2007-10-29, 4:27 am |
| On Oct 25, 5:07 pm, parthaspand...@gmail.com wrote:
> I am trying to understand what requirements are expected from ASTs by
> Debuggers and Source Browsers.
>
debuggers use debug info embedded in the binary. In the trvial case,
when you have unoptimized code, you can just dump source line info
that enables a debugger tyo browse code and step through lines of
source code.
In the non-trivial case, when code has been optimized -you do not
have a 1-to-1 match between object code and source code. So, the debug
info (maybe a .debug section in ELF) will allow the debugger to
examine variables and step through source code as if no dead-code
elimination has taken place and no data variables have been deleted/
optimized.
> I understand that bison provides support for --locations which can act
> as a base on which to build extensive source context information.
>
that would be input from the front-end -but a lot of info is dumped
from the back-end.
> How do we build upon that base? I have a vague memory of extensive
> source correspondence support in the EDG IL. Unfortunately, I dont own
> a copy so I have to rely upon memory which isnt much.
>
haven't worked on EDG front-ends yet.
> I dont think gcc supports source browsing, so are there any other
it does. Just use the -g flag to produce debug output when compiling,
and you can use gdb to step through lines of code and display
variables.
> reasonably complete implementations in the public domain that can
> provide an exhaustive view of things that source browsers and
> debuggers expect from a FE including and in addition to locations?
>
umm -a lot of info is generated during optimization, so that is partly
after front-end optimization, and some after back-end optimization.
The parser/AST in itself doesn't need to be modified much for that.
> I have heard of the phrase "automated tree construction". What exactly
> do they accomplish? I admit, expecting automation for my problem is
> probably too much, but I take the risk of asking about it.
>
isn't that for re-targetable code generation?
thanks
-kamal
|
|
|
|
|