This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] Running the inferior from breakpoint commands


Eli Zaretskii wrote:

> (I did look in the manual, but since the snippet you cited isn't
> indexed, I didn't find it.  [Yes, I will submit a manual change to add
> an index entry.])

http://sourceware.cygnus.com/gdb/onlinedocs/gdb_6.html#SEC34
four or five paragraphs down.

> To me, the fact that the test suite tried to do this was a sign that
> it was supposed to work.

Not a very reliable guide, I'm afraid.  That test was added in
1995, but as far as I know it did not work even then.  Perhaps
no one knew that it didn't.

> As an aside: is there any place I can find the list of tests which
> fail, and on what systems do they fail?

I'm afraid not.  Such a list would change daily.

> > If you seriously want to undertake this project, we can
> > work on a list of criteria that should be tested (things
> > that can go wrong).
> 
> I will put it on my todo (thanks for the list of things to test; 

Remember it was just a partial list off the top of my head.
I'm sure there are lots more issues to consider.

> > On top of that, I have grave concerns about being able
> > to correctly save and restore all of the internal
> > debugger state necessary to make this work (the
> > infrun execution state, the expression chain, etc.)
> 
> Err... I'm not sure this should be of concern here (but perhaps I
> don't see the subtle issues clearly enough): if the breakpoint
> commands change any of these global entities, I think the user expects
> the changes to be visible after these commands are processed.  For
> example, if the commands delete the breakpoint where you stopped, the
> user will expect the breakpoint to remain deleted after that (the
> changes I submitted do handle this specific case).  Am I missing
> something?

I'm not talking about anything user-visible -- I'm talking about
GDB's internal state.  All the variables with which it keeps 
track of what it's doing and what the child program is doing.
I don't have anything specific in mind, I just know there is
a lot to think about.

Michael

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]