Re: dynamic breakpoints/watchpoints

["Ed S. Peschko" <esp5 at pge dot com>]

> I still don't see what you mean. From your use case it is not clear why
> you would like to search the source code, rather than put a break-point
> on the FILE or stream.
> I always hated the perl debugger (maybe it is now better!), so any
> change to its old state should have had a radical productivity
> improvement. This does not mean that such a modification to GDB
> will have the same effect (it might, but I don't understand it from
> your example, can you give a better example?)
> 

Ok, just to be clear and to recap. I had two use cases in mind, one for 
breaking via searching data, one for breaking via searching code.

For searching code, I think that we are pretty much talking about the same thing.

    bc /hello there/ 

would break at the next point where the string 'hello there' was in the code; or 
set multiple breakpoints the same way that rbreak does (although I'm really skeptical
how it could do this for the case of, say libraries loaded at runtime and that have
not been loaded yet, which you could do with a runtime implementation.)


For searching data, I think we are close. I think we just differ in the details. 
I'm talking about a universal data searching mechanism, such that if you say:

    int main()
    {
        string a = "hello";

        a.append(" there");
        cout << a <<endl;
    }

    (gdb) bd /hello there/


it would break at the point in the c++ code where a became 'hello there'.

I think it should be implemented as hooks in the gcc compiler that talk to gdb,
you think that it should be implemented as part as libstdc++ and glibc.


My reason for preferring gcc over glibc is because of portability and universality. 
libstdc++ might be highly portable, but 99% of the open source packages are 
implemented in c, and glibc is highly linux specific. 

I would think that gcc could be tweaked to make a function call after any statement 
that does a data write, and that gdb could be tweaked to break at any point that the 
desired pattern is found, but I didn't develop gcc, so that's probably a question for them.



Anyways, as far as the perl debugger is concerned, I don't want to start a flame war, 
but IMO its more powerful than gdb as it stands, whether or not these features are 
implemented: for it allows you to inject any interpreted code you want at runtime at
any point in the execution stream, and have that code interact with variables inside
the running program.

I ended up implementing the code and data searching because I found myself swamped 
with code that I didn't write and still needed to maintain, and because it was far 
easier to look at what the code *produced* to deduce what it was doing rather than 
the code *itself*.  That's how I primarily use this - as a quick way to understand 
what is going on in a program without lots of code scrutiny.


Ed

(
    ps - I don't know gdb as much as the perl debugger, so I don't know - 
         maybe it is possible to do the same thing with gdb. I know you 
         can set variables in gdb, but I don't know if you can insert 
         whole blocks of c-code before or after a certain point..  
         I'd love to be able to do this, too..
)