Re: Requirements from ASTs by Debuggers and Source Browsers

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

Return to the comp.compilers page.
Search the comp.compilers archives again.