* GDB Python API: stop/continue after breakpoint @ 2011-03-11 16:09 Kevin Pouget 2011-03-11 16:25 ` Phil Muldoon 0 siblings, 1 reply; 12+ messages in thread From: Kevin Pouget @ 2011-03-11 16:09 UTC (permalink / raw) To: gdb Hello, I've tried the GDB python interface today, which seems quite efficient, but there is one important thing I couldn't figure out by myself: how to restart GDB when a[n internal] breakpoint is hit ? from the testsuite I've got this code: def breakpoint_stop_handler (event): if (isinstance (event, gdb.StopEvent)): print "event type: stop" if (isinstance (event, gdb.BreakpointEvent)): print "stop reason: breakpoint" print "breakpoint number: %s" % (event.breakpoint.number) if ( event.inferior_thread is not None) : print "thread num: %s" % (event.inferior_thread.num); else: print "all threads stopped" gdb.events.stop.connect (breakpoint_stop_handler) which where I get the notification of the stop, but I'd to be able to tell GDB something like enum bpstat_what_main_action { /* Remove breakpoints, single step once, then put them back in and go back to what we were doing. It's possible that this should be removed from the main_action and put into a separate field, to more cleanly handle BPSTAT_WHAT_CLEAR_LONGJMP_RESUME_SINGLE. */ BPSTAT_WHAT_SINGLE, /* Stop silently. */ BPSTAT_WHAT_STOP_SILENT, /* Stop and print. */ BPSTAT_WHAT_STOP_NOISY, ... } to continue silently, stop silently or print the breakpoint hit. is it possible at this stage ? Thanks, Kevin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB Python API: stop/continue after breakpoint 2011-03-11 16:09 GDB Python API: stop/continue after breakpoint Kevin Pouget @ 2011-03-11 16:25 ` Phil Muldoon [not found] ` <AANLkTin_a87WgchmZnzi9_XX4DXh8q-r3P7EyyDAzTA4@mail.gmail.com> 2011-03-21 14:20 ` Kevin Pouget 0 siblings, 2 replies; 12+ messages in thread From: Phil Muldoon @ 2011-03-11 16:25 UTC (permalink / raw) To: Kevin Pouget; +Cc: gdb Kevin Pouget <kevin.pouget@gmail.com> writes: > Hello, > > I've tried the GDB python interface today, which seems quite > efficient, but there is one important thing I couldn't figure out by > myself: > > how to restart GDB when a[n internal] breakpoint is hit ? > from the testsuite I've got this code: You almost can. One part is pending: http://sourceware.org/ml/gdb-patches/2011-03/msg00656.html The implementation of the "stop" API. The idea behind this is that if a breakpoint is hit, that is tracked from Python and has an implemented stop method, that method would be called. You can do what you like in that method. If you want the inferior process to continue, return True otherwise return False (and print out/do whatever else you need to do in Python). Because internal breakpoints are not tracked by default in the Python Breakpoint API, you would have to create your breakpoint by instantiating a gdb.Breakpoint class, and pass the keyword internal=True. So, long story short soon. OTOH I'm not sure if there is a unhacky way of doing it now. You could use a convenience function, but that patch is replacing that hacky way. Cheers Phil > > def breakpoint_stop_handler (event): > if (isinstance (event, gdb.StopEvent)): > print "event type: stop" > if (isinstance (event, gdb.BreakpointEvent)): > print "stop reason: breakpoint" > print "breakpoint number: %s" % (event.breakpoint.number) > if ( event.inferior_thread is not None) : > print "thread num: %s" % (event.inferior_thread.num); > else: > print "all threads stopped" > > gdb.events.stop.connect (breakpoint_stop_handler) > > > which where I get the notification of the stop, but I'd to be able to > tell GDB something like > > enum bpstat_what_main_action { > /* Remove breakpoints, single step once, then put them back in and > go back to what we were doing. It's possible that this should > be removed from the main_action and put into a separate field, > to more cleanly handle BPSTAT_WHAT_CLEAR_LONGJMP_RESUME_SINGLE. */ > BPSTAT_WHAT_SINGLE, > /* Stop silently. */ > BPSTAT_WHAT_STOP_SILENT, > > /* Stop and print. */ > BPSTAT_WHAT_STOP_NOISY, > ... > } > > to continue silently, stop silently or print the breakpoint hit. > > is it possible at this stage ? > > Thanks, > > Kevin ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <AANLkTin_a87WgchmZnzi9_XX4DXh8q-r3P7EyyDAzTA4@mail.gmail.com>]
* Re: GDB Python API: stop/continue after breakpoint [not found] ` <AANLkTin_a87WgchmZnzi9_XX4DXh8q-r3P7EyyDAzTA4@mail.gmail.com> @ 2011-03-11 17:52 ` Kevin Pouget 2011-04-20 14:59 ` Kevin Pouget 2011-04-20 15:20 ` Tom Tromey 0 siblings, 2 replies; 12+ messages in thread From: Kevin Pouget @ 2011-03-11 17:52 UTC (permalink / raw) Cc: gdb thanks for your answer, the patch seems to feature what I was looking for. I'm a bit surprised that the stop/continue decision can't be done in this breakpoint_stop handler, but I guess that was too complicated ? > On Fri, Mar 11, 2011 at 5:25 PM, Phil Muldoon <pmuldoon@redhat.com> wrote: >> >> Kevin Pouget <kevin.pouget@gmail.com> writes: >> >> > Hello, >> > >> > I've tried the GDB python interface today, which seems quite >> > efficient, but there is one important thing I couldn't figure out by >> > myself: >> > >> > how to restart GDB when a[n internal] breakpoint is hit ? >> > from the testsuite I've got this code: >> >> >> You almost can. One part is pending: >> >> http://sourceware.org/ml/gdb-patches/2011-03/msg00656.html >> >> The implementation of the "stop" API. The idea behind this is that if a >> breakpoint is hit, that is tracked from Python and has an implemented >> stop method, that method would be called. You can do what you like in >> that method. If you want the inferior process to continue, return True >> otherwise return False (and print out/do whatever else you need to do in >> Python). >> >> Because internal breakpoints are not tracked by default in the Python >> Breakpoint API, you would have to create your breakpoint by >> instantiating a gdb.Breakpoint class, and pass the keyword >> internal=True. >> >> So, long story short soon. OTOH I'm not sure if there is a unhacky way >> of doing it now. You could use a convenience function, but that patch >> is replacing that hacky way. >> >> Cheers >> >> Phil >> > >> > def breakpoint_stop_handler (event): >> > if (isinstance (event, gdb.StopEvent)): >> > print "event type: stop" >> > if (isinstance (event, gdb.BreakpointEvent)): >> > print "stop reason: breakpoint" >> > print "breakpoint number: %s" % (event.breakpoint.number) >> > if ( event.inferior_thread is not None) : >> > print "thread num: %s" % (event.inferior_thread.num); >> > else: >> > print "all threads stopped" >> > >> > gdb.events.stop.connect (breakpoint_stop_handler) >> > >> > >> > which where I get the notification of the stop, but I'd to be able to >> > tell GDB something like >> > >> > enum bpstat_what_main_action { >> > /* Remove breakpoints, single step once, then put them back in and >> > go back to what we were doing. It's possible that this should >> > be removed from the main_action and put into a separate field, >> > to more cleanly handle BPSTAT_WHAT_CLEAR_LONGJMP_RESUME_SINGLE. */ >> > BPSTAT_WHAT_SINGLE, >> > /* Stop silently. */ >> > BPSTAT_WHAT_STOP_SILENT, >> > >> > /* Stop and print. */ >> > BPSTAT_WHAT_STOP_NOISY, >> > ... >> > } >> > >> > to continue silently, stop silently or print the breakpoint hit. >> > >> > is it possible at this stage ? >> > >> > Thanks, >> > >> > Kevin > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB Python API: stop/continue after breakpoint 2011-03-11 17:52 ` Kevin Pouget @ 2011-04-20 14:59 ` Kevin Pouget 2011-04-20 15:15 ` Phil Muldoon 2011-04-20 15:39 ` Tom Tromey 2011-04-20 15:20 ` Tom Tromey 1 sibling, 2 replies; 12+ messages in thread From: Kevin Pouget @ 2011-04-20 14:59 UTC (permalink / raw) To: pmuldoon, gdb Hello, I'm coming back to this post because I've got a bit of an issue here: basically, I need (and I'm looking for to helping for it!) a sharp control of the inferior execution from the python interface, but I'm facing some limitations: * in MyBreakpoint.stop(), I can say continue/stop the inferior, but I can't run "finish" (or "next" or what ever, I guess), because the inferior is still considered as running: > "gdb.error: Cannot execute this command while the selected thread is running." * in event.stop.connect() that's possible, but I can't `gdb.execute("continue")' the execution because I would miss any "non-python" reasons to stop (ie, a user-breakpoint, a signal ...) let me know if my problem is not clear, and if you have any comment / idea on how to solve it cordially, Kevin On Fri, Mar 11, 2011 at 12:52 PM, Kevin Pouget <kevin.pouget@gmail.com> wrote: > thanks for your answer, the patch seems to feature what I was looking for. > > I'm a bit surprised that the stop/continue decision can't be done in > this breakpoint_stop handler, but I guess that was too complicated ? > >> On Fri, Mar 11, 2011 at 5:25 PM, Phil Muldoon <pmuldoon@redhat.com> wrote: >>> >>> Kevin Pouget <kevin.pouget@gmail.com> writes: >>> >>> > Hello, >>> > >>> > I've tried the GDB python interface today, which seems quite >>> > efficient, but there is one important thing I couldn't figure out by >>> > myself: >>> > >>> > how to restart GDB when a[n internal] breakpoint is hit ? >>> > from the testsuite I've got this code: >>> >>> >>> You almost can. One part is pending: >>> >>> http://sourceware.org/ml/gdb-patches/2011-03/msg00656.html >>> >>> The implementation of the "stop" API. The idea behind this is that if a >>> breakpoint is hit, that is tracked from Python and has an implemented >>> stop method, that method would be called. You can do what you like in >>> that method. If you want the inferior process to continue, return True >>> otherwise return False (and print out/do whatever else you need to do in >>> Python). >>> >>> Because internal breakpoints are not tracked by default in the Python >>> Breakpoint API, you would have to create your breakpoint by >>> instantiating a gdb.Breakpoint class, and pass the keyword >>> internal=True. >>> >>> So, long story short soon. OTOH I'm not sure if there is a unhacky way >>> of doing it now. You could use a convenience function, but that patch >>> is replacing that hacky way. >>> >>> Cheers >>> >>> Phil >>> > >>> > def breakpoint_stop_handler (event): >>> > if (isinstance (event, gdb.StopEvent)): >>> > print "event type: stop" >>> > if (isinstance (event, gdb.BreakpointEvent)): >>> > print "stop reason: breakpoint" >>> > print "breakpoint number: %s" % (event.breakpoint.number) >>> > if ( event.inferior_thread is not None) : >>> > print "thread num: %s" % (event.inferior_thread.num); >>> > else: >>> > print "all threads stopped" >>> > >>> > gdb.events.stop.connect (breakpoint_stop_handler) >>> > >>> > >>> > which where I get the notification of the stop, but I'd to be able to >>> > tell GDB something like >>> > >>> > enum bpstat_what_main_action { >>> > /* Remove breakpoints, single step once, then put them back in and >>> > go back to what we were doing. It's possible that this should >>> > be removed from the main_action and put into a separate field, >>> > to more cleanly handle BPSTAT_WHAT_CLEAR_LONGJMP_RESUME_SINGLE. */ >>> > BPSTAT_WHAT_SINGLE, >>> > /* Stop silently. */ >>> > BPSTAT_WHAT_STOP_SILENT, >>> > >>> > /* Stop and print. */ >>> > BPSTAT_WHAT_STOP_NOISY, >>> > ... >>> > } >>> > >>> > to continue silently, stop silently or print the breakpoint hit. >>> > >>> > is it possible at this stage ? >>> > >>> > Thanks, >>> > >>> > Kevin >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB Python API: stop/continue after breakpoint 2011-04-20 14:59 ` Kevin Pouget @ 2011-04-20 15:15 ` Phil Muldoon 2011-04-20 15:39 ` Tom Tromey 1 sibling, 0 replies; 12+ messages in thread From: Phil Muldoon @ 2011-04-20 15:15 UTC (permalink / raw) To: Kevin Pouget; +Cc: gdb Kevin Pouget <kevin.pouget@gmail.com> writes: > Hello, > > I'm coming back to this post because I've got a bit of an issue here: > > basically, I need (and I'm looking for to helping for it!) a sharp > control of the inferior execution from the python interface, but I'm > facing some limitations: > > * in MyBreakpoint.stop(), I can say continue/stop the inferior, but I > can't run "finish" (or "next" or what ever, I guess), because the > inferior is still considered as running: >> "gdb.error: Cannot execute this command while the selected thread is running." At this point GDB is deciding whether to stop the inferior and return control to the console or not. (Really, at this point, the inferior is stopped, by ptrace, but GDB is trying to work out if it should really maintain the stop, or resume the inferior). So in GDB's internal data store, the inferior (thread) is still "running" and will be so until a firm stop decision is reached. Because of this intermediate state, you cannot issue cannot step/next/continue/finish or other inferior control commands. This is really a very simplistic view of what is going on. I've glossed over a lot. > * in event.stop.connect() that's possible, but I can't > `gdb.execute("continue")' the execution because I would miss any > "non-python" reasons to stop (ie, a user-breakpoint, a signal ...) The only thing I can think to do here is set some of your own data in your Python module. Breakpoint.stop sets some flag or data, and the event.connect can pick up on that. But there are gaps in the API. File bugs, I look there daily. I hope this helped some! Cheers, Phil ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB Python API: stop/continue after breakpoint 2011-04-20 14:59 ` Kevin Pouget 2011-04-20 15:15 ` Phil Muldoon @ 2011-04-20 15:39 ` Tom Tromey 2011-04-21 13:01 ` Kevin Pouget 1 sibling, 1 reply; 12+ messages in thread From: Tom Tromey @ 2011-04-20 15:39 UTC (permalink / raw) To: Kevin Pouget; +Cc: pmuldoon, gdb >>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes: Kevin> * in MyBreakpoint.stop(), I can say continue/stop the inferior, but I Kevin> can't run "finish" (or "next" or what ever, I guess), because the Kevin> inferior is still considered as running: I think it would be pretty difficult to get this to work. Kevin> * in event.stop.connect() that's possible, but I can't Kevin> `gdb.execute("continue")' the execution because I would miss any Kevin> "non-python" reasons to stop (ie, a user-breakpoint, a signal ...) I think you should be able to examine the stop event object to see what caused the event. If the event is a gdb.BreakpointEvent, and if event.breakpoint is your breakpoint, then do what you want. Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB Python API: stop/continue after breakpoint 2011-04-20 15:39 ` Tom Tromey @ 2011-04-21 13:01 ` Kevin Pouget [not found] ` <BANLkTinwMfsxA24q-5ekbapVdM_OP6rOsQ@mail.gmail.com> 0 siblings, 1 reply; 12+ messages in thread From: Kevin Pouget @ 2011-04-21 13:01 UTC (permalink / raw) To: Tom Tromey; +Cc: pmuldoon, gdb > Kevin> * in event.stop.connect() that's possible, but I can't > Kevin> `gdb.execute("continue")' the execution because I would miss any > Kevin> "non-python" reasons to stop (ie, a user-breakpoint, a signal ...) > > I think you should be able to examine the stop event object to see what > caused the event. If the event is a gdb.BreakpointEvent, and if > event.breakpoint is your breakpoint, then do what you want. I'm afraid that's impossible to do it with the current implementation, look: def handle_double_stop(event): print "Stop event: ", event.breakpoint.number gdb.events.stop.connect(handle_double_stop) (gdb) break main Breakpoint 1 (gdb) break main Breakpoint 2 (gdb) run Stop event: 1 ... as far as I know, there is no 'easy' way to know that Bp 2 was hit as well ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <BANLkTinwMfsxA24q-5ekbapVdM_OP6rOsQ@mail.gmail.com>]
* Re: GDB Python API: stop/continue after breakpoint [not found] ` <BANLkTinwMfsxA24q-5ekbapVdM_OP6rOsQ@mail.gmail.com> @ 2011-04-21 14:32 ` Kevin Pouget 0 siblings, 0 replies; 12+ messages in thread From: Kevin Pouget @ 2011-04-21 14:32 UTC (permalink / raw) To: gdb before I start any implementation, would you agree if I change > int > emit_stop_event (struct bpstats *bs, enum target_signal stop_signal) > ... > if (bs && bs->breakpoint_at > && bs->breakpoint_at->py_bp_object) > { > stop_event_obj = create_breakpoint_event_object ((PyObject *) bs > ->breakpoint_at > ->py_bp_object); > } so that it browses the `bs->next' list and returns a python tuple instead of a single object ? > /* Linked list because there can be more than one breakpoint at > the same place, and a bpstat reflects the fact that all have > been hit. */ > bpstat next; Cordially, Kevin On Thu, Apr 21, 2011 at 9:01 AM, Kevin Pouget <kevin.pouget@gmail.com> wrote: >> Kevin> * in event.stop.connect() that's possible, but I can't >> Kevin> `gdb.execute("continue")' the execution because I would miss any >> Kevin> "non-python" reasons to stop (ie, a user-breakpoint, a signal ...) >> >> I think you should be able to examine the stop event object to see what >> caused the event. If the event is a gdb.BreakpointEvent, and if >> event.breakpoint is your breakpoint, then do what you want. > > I'm afraid that's impossible to do it with the current implementation, look: > > def handle_double_stop(event): > print "Stop event: ", event.breakpoint.number > gdb.events.stop.connect(handle_double_stop) > > (gdb) break main > Breakpoint 1 > (gdb) break main > Breakpoint 2 > (gdb) run > Stop event: 1 > > ... as far as I know, there is no 'easy' way to know that Bp 2 was hit as well > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB Python API: stop/continue after breakpoint 2011-03-11 17:52 ` Kevin Pouget 2011-04-20 14:59 ` Kevin Pouget @ 2011-04-20 15:20 ` Tom Tromey 1 sibling, 0 replies; 12+ messages in thread From: Tom Tromey @ 2011-04-20 15:20 UTC (permalink / raw) To: Kevin Pouget; +Cc: gdb >>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes: Sorry, I didn't notice this until your follow-up. Kevin> thanks for your answer, the patch seems to feature what I was Kevin> looking for. I'm a bit surprised that the stop/continue decision Kevin> can't be done in this breakpoint_stop handler, but I guess that Kevin> was too complicated ? We intentionally made event handlers not return values. My recollection is that this was done both due to simplicity and also out of the desire to make it clear that event handlers ought to be logically separate. Once handlers affect other handlers, the coding gets more complicated, and it seems better to associate such actions more directly with their causes. Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB Python API: stop/continue after breakpoint 2011-03-11 16:25 ` Phil Muldoon [not found] ` <AANLkTin_a87WgchmZnzi9_XX4DXh8q-r3P7EyyDAzTA4@mail.gmail.com> @ 2011-03-21 14:20 ` Kevin Pouget 2011-03-21 14:39 ` Phil Muldoon 1 sibling, 1 reply; 12+ messages in thread From: Kevin Pouget @ 2011-03-21 14:20 UTC (permalink / raw) To: pmuldoon; +Cc: gdb cool, that's working perfectly now ! just one thing: > <python breakpoint outputs> > > [Switching to Thread 0x7ffff7de1700 (LWP 2417)] > > Breakpoint -9, rdb_notify_event () at replay_db.c:11 > 11 void rdb_notify_event() {} is there any way / woudn't it be nice to have the ability to disable the breakpoint hit outputs? at least for the 'internal' breakpoints, which shouldn't be visible to the user ? Thanks, Kevin On Fri, Mar 11, 2011 at 11:25 AM, Phil Muldoon <pmuldoon@redhat.com> wrote: > > Kevin Pouget <kevin.pouget@gmail.com> writes: > > > Hello, > > > > I've tried the GDB python interface today, which seems quite > > efficient, but there is one important thing I couldn't figure out by > > myself: > > > > how to restart GDB when a[n internal] breakpoint is hit ? > > from the testsuite I've got this code: > > > You almost can. One part is pending: > > http://sourceware.org/ml/gdb-patches/2011-03/msg00656.html > > The implementation of the "stop" API. The idea behind this is that if a > breakpoint is hit, that is tracked from Python and has an implemented > stop method, that method would be called. You can do what you like in > that method. If you want the inferior process to continue, return True > otherwise return False (and print out/do whatever else you need to do in > Python). > > Because internal breakpoints are not tracked by default in the Python > Breakpoint API, you would have to create your breakpoint by > instantiating a gdb.Breakpoint class, and pass the keyword > internal=True. > > So, long story short soon. OTOH I'm not sure if there is a unhacky way > of doing it now. You could use a convenience function, but that patch > is replacing that hacky way. > > Cheers > > Phil > > > > def breakpoint_stop_handler (event): > > if (isinstance (event, gdb.StopEvent)): > > print "event type: stop" > > if (isinstance (event, gdb.BreakpointEvent)): > > print "stop reason: breakpoint" > > print "breakpoint number: %s" % (event.breakpoint.number) > > if ( event.inferior_thread is not None) : > > print "thread num: %s" % (event.inferior_thread.num); > > else: > > print "all threads stopped" > > > > gdb.events.stop.connect (breakpoint_stop_handler) > > > > > > which where I get the notification of the stop, but I'd to be able to > > tell GDB something like > > > > enum bpstat_what_main_action { > > /* Remove breakpoints, single step once, then put them back in and > > go back to what we were doing. It's possible that this should > > be removed from the main_action and put into a separate field, > > to more cleanly handle BPSTAT_WHAT_CLEAR_LONGJMP_RESUME_SINGLE. */ > > BPSTAT_WHAT_SINGLE, > > /* Stop silently. */ > > BPSTAT_WHAT_STOP_SILENT, > > > > /* Stop and print. */ > > BPSTAT_WHAT_STOP_NOISY, > > ... > > } > > > > to continue silently, stop silently or print the breakpoint hit. > > > > is it possible at this stage ? > > > > Thanks, > > > > Kevin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB Python API: stop/continue after breakpoint 2011-03-21 14:20 ` Kevin Pouget @ 2011-03-21 14:39 ` Phil Muldoon 2011-03-21 15:11 ` Kevin Pouget 0 siblings, 1 reply; 12+ messages in thread From: Phil Muldoon @ 2011-03-21 14:39 UTC (permalink / raw) To: Kevin Pouget; +Cc: gdb Kevin Pouget <kevin.pouget@gmail.com> writes: > cool, that's working perfectly now ! > > just one thing: > >> <python breakpoint outputs> >> >> [Switching to Thread 0x7ffff7de1700 (LWP 2417)] >> >> Breakpoint -9, rdb_notify_event () at replay_db.c:11 >> 11 void rdb_notify_event() {} > > is there any way / woudn't it be nice to have the ability to disable > the breakpoint hit outputs? at least for the 'internal' breakpoints, > which shouldn't be visible to the user ? You can set the breakpoint to silent: (gdb) python b = gdb.Breakpoint("hello.c:5", internal=True) (gdb) run Breakpoint -1, main () at /home/pmuldoon/hello.c:5 5 printf("Hello world!\n"); (gdb) py b.silent = True (gdb) run (gdb) list (gdb) where #0 main () at /home/pmuldoon/hello.c:5 There might be a case for setting the breakpoint to 'silent' in the breakpoint constructor: python b = gdb.Breakpoint("hello.c:5", internal=True, silent=True) or just making internal breakpoints silent by default. I'll implement either. What do you think? Cheers, Phil ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB Python API: stop/continue after breakpoint 2011-03-21 14:39 ` Phil Muldoon @ 2011-03-21 15:11 ` Kevin Pouget 0 siblings, 0 replies; 12+ messages in thread From: Kevin Pouget @ 2011-03-21 15:11 UTC (permalink / raw) To: pmuldoon; +Cc: gdb > (gdb) py b.silent = True very nice! I was just reading an old post http://sourceware.org/ml/gdb/2007-04/msg00127.html about a plugin vs scripting interface, Python finally get the point, it's now easier to write a Python script which handles breakpoints than a GDB patch! > There might be a case for setting the breakpoint to 'silent' in the > breakpoint constructor: > > python b = gdb.Breakpoint("hello.c:5", internal=True, silent=True) > > or just making internal breakpoints silent by default. > > I'll implement either. What do you think? from my perspective, _internal breakpoints_ should be silent by default, because they're 'internal', as their name says. Option 1) is quite similar `b.silent`, so it's up to you Cordially, Kevin ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-04-21 14:32 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-03-11 16:09 GDB Python API: stop/continue after breakpoint Kevin Pouget 2011-03-11 16:25 ` Phil Muldoon [not found] ` <AANLkTin_a87WgchmZnzi9_XX4DXh8q-r3P7EyyDAzTA4@mail.gmail.com> 2011-03-11 17:52 ` Kevin Pouget 2011-04-20 14:59 ` Kevin Pouget 2011-04-20 15:15 ` Phil Muldoon 2011-04-20 15:39 ` Tom Tromey 2011-04-21 13:01 ` Kevin Pouget [not found] ` <BANLkTinwMfsxA24q-5ekbapVdM_OP6rOsQ@mail.gmail.com> 2011-04-21 14:32 ` Kevin Pouget 2011-04-20 15:20 ` Tom Tromey 2011-03-21 14:20 ` Kevin Pouget 2011-03-21 14:39 ` Phil Muldoon 2011-03-21 15:11 ` Kevin Pouget
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).