This is the mail archive of the gdb-patches@sourceware.org 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]
Other format: [Raw text]

Re: [PATCH v2] dynamic printf


>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:

Tom> I thought this approach would break "next"ing over a dprintf location.

Stan> Indeed, thus this part of the introduction to this patch: :-)

I you read the binutils list today you'll see I'm quite off my game.
Sorry about the poor reading comprehension.

Stan> "... Joel previously noted a problem with the "continue" in the
Stan> command list, which is that stepping/nexting over a dprintf becomes a
Stan> continue instead (this is a problem for general breakpoint command
Stan> lists as well).  I tinkered with bpstats a bit, but didn't come up
Stan> with a good solution.  One possibility might be a new pseudo-command
Stan> for breakpoint command lists, that resumes the program using the same
Stan> proceed() arguments as the command that caused the breakpoint hit."

Yeah, we added the 'stop' machinery to Python to let us deal with this.

One idea would be "continue -hey-dont-break-next"

Stan> If nobody comes up with a good idea here, it should probably be
Stan> documented as a limitation.  I wonder if some relatively recent infrun
Stan> tinkering changed the breakpoint command behavior - you'd think
Stan> *somebody* would have bumped into it sometime in the past 20 years...

I've known about it for a long time, I think we all just worked around
it.

Tom


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