lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


It's very fast when you have all breapoint data locally (in debugger where
program goes)
But what if user wants to set breakpoint during program execution? or do a
execution break?
I have to ask debugging editor about every execution line in that situation.
Cheers

----- Original Message -----
From: "Benoit Germain" <bgermain@ubisoft.fr>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
Sent: Friday, July 05, 2002 9:47 AM
Subject: RE: remote debug


> I am currently experimenting with such a scheme (lua state + debug stub on
> target platform, binding to a tcp socket opened by the server side).
> What I do is store all relevant information in the host application, and
the
> debugger is only a display (i am concentrating on the debugger features,
and
> my display is a console for now). Everything is stored in a table created
in
> the state's registry, including breakpoints.
> Those are in a separate table, where the key is a string formed from the
> file name and the line number, and the value is a lua string. The line
hook
> fetches an entry in this table, if non-nil, evaluates the lua string, and
> breaks if the result is non-nil.
> Since I don't intend to have several dozens breakpoints when debugging, I
> hope the memory penalty should remain reasonable. Not sure a table access
at
> every line will speed up things, though :-)
>
> Well, I'm not done yet, but I see no reason why it would not work, unless
> evaluating a lua string is not possible inside the line hook ?
>
> Cheers,
>
> Benoit
>
> > -----Original Message-----
> > From: Tristan Rybak [mailto:tristan.rybak@wp.pl]
> > Sent: jeudi 4 juillet 2002 21:19
> > To: Multiple recipients of list
> > Subject: remote debug
> >
> >
> > I am thinking where to keep information about breakpoints
> > during remote
> > debug:
> > 1. send all breakpoint information to client debug stub -> for small
> > embedded environments it has a big hit on memory...
> > 2. keep all debug info in debugger -> big hit on performance
> > because client
> > must ask debugger every debug line what to do.
> > What do You gurus think?
> > Cheers
> > Tristan
> >
> >
>