* [rfc] Print solib events in mi-mode @ 2003-07-08 20:35 Kris Warkentin 2003-07-08 21:02 ` Andrew Cagney 2003-07-09 20:38 ` Jason Molenda 0 siblings, 2 replies; 21+ messages in thread From: Kris Warkentin @ 2003-07-08 20:35 UTC (permalink / raw) To: Gdb@Sources.Redhat.Com What do you think of something like this? When stop-on-solib-events is set, this will print the reason as being a shared-lib-event. Our Eclipse team wants to be able to set breakpoints in shared libraries that aren't loaded yet. If they get notification of shlib-events, then they can re-examine the list of loaded libraries and set any breakpoints that have been enabled in the project's libs. cheers, Kris $ cvs diff -u breakpoint.c Index: breakpoint.c =================================================================== RCS file: /cvs/src/src/gdb/breakpoint.c,v retrieving revision 1.125 diff -u -r1.125 breakpoint.c --- breakpoint.c 2 Jul 2003 16:24:00 -0000 1.125 +++ breakpoint.c 8 Jul 2003 20:32:50 -0000 @@ -2039,8 +2039,10 @@ /* Did we stop because the user set the stop_on_solib_events variable? (If so, we report this as a generic, "Stopped due to shlib event" message.) */ - printf_filtered ("Stopped due to shared library event\n"); - return PRINT_NOTHING; + ui_out_text (uiout, "\nShared library event "); + if (ui_out_is_mi_like_p (uiout)) + ui_out_field_string (uiout, "reason", "shared-lib-event"); + return PRINT_SRC_ONLY; break; case bp_thread_event: ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-08 20:35 [rfc] Print solib events in mi-mode Kris Warkentin @ 2003-07-08 21:02 ` Andrew Cagney 2003-07-09 12:24 ` Kris Warkentin 2003-07-09 20:38 ` Jason Molenda 1 sibling, 1 reply; 21+ messages in thread From: Andrew Cagney @ 2003-07-08 21:02 UTC (permalink / raw) To: Kris Warkentin; +Cc: Gdb@Sources.Redhat.Com > What do you think of something like this? When stop-on-solib-events is set, > this will print the reason as being a shared-lib-event. > > Our Eclipse team wants to be able to set breakpoints in shared libraries > that aren't loaded yet. If they get notification of shlib-events, then they > can re-examine the list of loaded libraries and set any breakpoints that > have been enabled in the project's libs. See: [RFC] add 'save-breakpoints' command http://sources.redhat.com/ml/gdb-patches/2001-12/threads.html#00114 (but check for other related threads). The resolution was interesting, instead of adding a new command, modify the existing command so that it would add breakpoints that would be automatically enabled later. Andrew (although the patch is probably also useful) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-08 21:02 ` Andrew Cagney @ 2003-07-09 12:24 ` Kris Warkentin 2003-07-09 15:09 ` Daniel Jacobowitz 0 siblings, 1 reply; 21+ messages in thread From: Kris Warkentin @ 2003-07-09 12:24 UTC (permalink / raw) To: Andrew Cagney; +Cc: Gdb@Sources.Redhat.Com Actually, I had looked at those and some other related threads. I suggested to our Eclipse guys that it would probably be easy for them to just implement it in the IDE (since all the apps and libs are already projects under IDE control) using the stop-on-solib-event mechanism. They countered that there was no mi feedback on whether an stop was solib related, hence my patch. If there's no objection to the output this provides, I wouldn't mind applying it. MI-ification is generally a good thing right? Is there somewhere I should document this as well? cheers, Kris ----- Original Message ----- From: "Andrew Cagney" <ac131313@redhat.com> To: "Kris Warkentin" <kewarken@qnx.com> Cc: "Gdb@Sources.Redhat.Com" <gdb@sources.redhat.com> Sent: Tuesday, July 08, 2003 5:02 PM Subject: Re: [rfc] Print solib events in mi-mode > > What do you think of something like this? When stop-on-solib-events is set, > > this will print the reason as being a shared-lib-event. > > > > Our Eclipse team wants to be able to set breakpoints in shared libraries > > that aren't loaded yet. If they get notification of shlib-events, then they > > can re-examine the list of loaded libraries and set any breakpoints that > > have been enabled in the project's libs. > > See: [RFC] add 'save-breakpoints' command > http://sources.redhat.com/ml/gdb-patches/2001-12/threads.html#00114 > (but check for other related threads). > > The resolution was interesting, instead of adding a new command, modify > the existing command so that it would add breakpoints that would be > automatically enabled later. > > Andrew > > (although the patch is probably also useful) > > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 12:24 ` Kris Warkentin @ 2003-07-09 15:09 ` Daniel Jacobowitz 2003-07-09 15:38 ` Kris Warkentin 0 siblings, 1 reply; 21+ messages in thread From: Daniel Jacobowitz @ 2003-07-09 15:09 UTC (permalink / raw) To: Kris Warkentin; +Cc: Andrew Cagney, Gdb@Sources.Redhat.Com On Wed, Jul 09, 2003 at 08:24:28AM -0400, Kris Warkentin wrote: > Actually, I had looked at those and some other related threads. I suggested > to our Eclipse guys that it would probably be easy for them to just > implement it in the IDE (since all the apps and libs are already projects > under IDE control) using the stop-on-solib-event mechanism. They countered > that there was no mi feedback on whether an stop was solib related, hence my > patch. > > If there's no objection to the output this provides, I wouldn't mind > applying it. MI-ification is generally a good thing right? Is there > somewhere I should document this as well? TBH, I'd rather see load catchpoints implemented and MI-ified for solib-svr4.c. The natural implementation returns more useful information, namely what libraries were loaded or unloaded. It should be easy but it's never trickled to the top of anyone's TODO. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 15:09 ` Daniel Jacobowitz @ 2003-07-09 15:38 ` Kris Warkentin 2003-07-09 16:24 ` Daniel Jacobowitz 0 siblings, 1 reply; 21+ messages in thread From: Kris Warkentin @ 2003-07-09 15:38 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Andrew Cagney, Gdb@Sources.Redhat.Com > On Wed, Jul 09, 2003 at 08:24:28AM -0400, Kris Warkentin wrote: > > Actually, I had looked at those and some other related threads. I suggested > > to our Eclipse guys that it would probably be easy for them to just > > implement it in the IDE (since all the apps and libs are already projects > > under IDE control) using the stop-on-solib-event mechanism. They countered > > that there was no mi feedback on whether an stop was solib related, hence my > > patch. > > > > If there's no objection to the output this provides, I wouldn't mind > > applying it. MI-ification is generally a good thing right? Is there > > somewhere I should document this as well? > > TBH, I'd rather see load catchpoints implemented and MI-ified for > solib-svr4.c. The natural implementation returns more useful > information, namely what libraries were loaded or unloaded. It should > be easy but it's never trickled to the top of anyone's TODO. What about solib-events on non-svr4 systems? QNX is implementing the CDT for Eclipse and we'd like to have equal functionality across platforms. cheers, Kris ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 15:38 ` Kris Warkentin @ 2003-07-09 16:24 ` Daniel Jacobowitz 2003-07-09 17:29 ` Kris Warkentin 0 siblings, 1 reply; 21+ messages in thread From: Daniel Jacobowitz @ 2003-07-09 16:24 UTC (permalink / raw) To: Kris Warkentin; +Cc: Andrew Cagney, Gdb@Sources.Redhat.Com On Wed, Jul 09, 2003 at 11:39:26AM -0400, Kris Warkentin wrote: > > On Wed, Jul 09, 2003 at 08:24:28AM -0400, Kris Warkentin wrote: > > > Actually, I had looked at those and some other related threads. I > suggested > > > to our Eclipse guys that it would probably be easy for them to just > > > implement it in the IDE (since all the apps and libs are already > projects > > > under IDE control) using the stop-on-solib-event mechanism. They > countered > > > that there was no mi feedback on whether an stop was solib related, > hence my > > > patch. > > > > > > If there's no objection to the output this provides, I wouldn't mind > > > applying it. MI-ification is generally a good thing right? Is there > > > somewhere I should document this as well? > > > > TBH, I'd rather see load catchpoints implemented and MI-ified for > > solib-svr4.c. The natural implementation returns more useful > > information, namely what libraries were loaded or unloaded. It should > > be easy but it's never trickled to the top of anyone's TODO. > > What about solib-events on non-svr4 systems? QNX is implementing the CDT > for Eclipse and we'd like to have equal functionality across platforms. I picked on solib-svr4 because it's the one normally found lacking. At least one of the solib backends already does this - probably SOM? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 16:24 ` Daniel Jacobowitz @ 2003-07-09 17:29 ` Kris Warkentin 2003-07-09 17:41 ` Kevin Buettner 0 siblings, 1 reply; 21+ messages in thread From: Kris Warkentin @ 2003-07-09 17:29 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Andrew Cagney, Gdb@Sources.Redhat.Com > On Wed, Jul 09, 2003 at 11:39:26AM -0400, Kris Warkentin wrote: > > > TBH, I'd rather see load catchpoints implemented and MI-ified for > > > solib-svr4.c. The natural implementation returns more useful > > > information, namely what libraries were loaded or unloaded. It should > > > be easy but it's never trickled to the top of anyone's TODO. > > > > What about solib-events on non-svr4 systems? QNX is implementing the CDT > > for Eclipse and we'd like to have equal functionality across platforms. > > I picked on solib-svr4 because it's the one normally found lacking. At > least one of the solib backends already does this - probably SOM? So you're saying that you're not receptive to this patch but you'd consider a svr4 patch for the load catchpoints? Kris ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 17:29 ` Kris Warkentin @ 2003-07-09 17:41 ` Kevin Buettner 2003-07-09 17:49 ` Kris Warkentin 0 siblings, 1 reply; 21+ messages in thread From: Kevin Buettner @ 2003-07-09 17:41 UTC (permalink / raw) To: Kris Warkentin, Daniel Jacobowitz; +Cc: Andrew Cagney, Gdb@Sources.Redhat.Com On Jul 9, 1:29pm, Kris Warkentin wrote: > > On Wed, Jul 09, 2003 at 11:39:26AM -0400, Kris Warkentin wrote: > > > > TBH, I'd rather see load catchpoints implemented and MI-ified for > > > > solib-svr4.c. The natural implementation returns more useful > > > > information, namely what libraries were loaded or unloaded. It should > > > > be easy but it's never trickled to the top of anyone's TODO. > > > > > > What about solib-events on non-svr4 systems? QNX is implementing the > CDT > > > for Eclipse and we'd like to have equal functionality across platforms. > > > > I picked on solib-svr4 because it's the one normally found lacking. At > > least one of the solib backends already does this - probably SOM? > > So you're saying that you're not receptive to this patch but you'd consider > a svr4 patch for the load catchpoints? If it could be moved out to solib.c, I'd be receptive to it. I'm also willing to look at a patch which modifies solib-svr4.c, but I'd prefer one which handles all off the solib backends in one fell swoop. Kevin ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 17:41 ` Kevin Buettner @ 2003-07-09 17:49 ` Kris Warkentin 2003-07-09 18:01 ` Kris Warkentin 2003-07-18 16:12 ` Andrew Cagney 0 siblings, 2 replies; 21+ messages in thread From: Kris Warkentin @ 2003-07-09 17:49 UTC (permalink / raw) To: Kevin Buettner, Daniel Jacobowitz; +Cc: Andrew Cagney, Gdb@Sources.Redhat.Com > > > On Wed, Jul 09, 2003 at 11:39:26AM -0400, Kris Warkentin wrote: > > > > > TBH, I'd rather see load catchpoints implemented and MI-ified for > > > > > solib-svr4.c. The natural implementation returns more useful > > > > > information, namely what libraries were loaded or unloaded. It should > > > > > be easy but it's never trickled to the top of anyone's TODO. > > > > > > > > What about solib-events on non-svr4 systems? QNX is implementing the > > CDT > > > > for Eclipse and we'd like to have equal functionality across platforms. > > > > > > I picked on solib-svr4 because it's the one normally found lacking. At > > > least one of the solib backends already does this - probably SOM? > > > > So you're saying that you're not receptive to this patch but you'd consider > > a svr4 patch for the load catchpoints? > > If it could be moved out to solib.c, I'd be receptive to it. I'm also > willing to look at a patch which modifies solib-svr4.c, but I'd prefer > one which handles all off the solib backends in one fell swoop. The patch is for breakpoint.c. It's in the print_it_typical() function which handles output when a breakpoint is hit. I'm not sure how I would put this into solib.c. cheers, Kris ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 17:49 ` Kris Warkentin @ 2003-07-09 18:01 ` Kris Warkentin 2003-07-09 18:05 ` Daniel Jacobowitz 2003-07-18 16:12 ` Andrew Cagney 1 sibling, 1 reply; 21+ messages in thread From: Kris Warkentin @ 2003-07-09 18:01 UTC (permalink / raw) To: Kris Warkentin, Kevin Buettner, Daniel Jacobowitz Cc: Andrew Cagney, Gdb@Sources.Redhat.Com Someone just pointed something out to me. "set stop-on-solib-events 1" is NOT enable-load-catchpoint or anything else. Yes, those things should exist for all solib platforms but the bottom line is that stop-on-solib-events is not currently mi-enabled and it should be. I want to make that command result in proper mi output, regardless of any other things which might be implemented in the future. cheers, Kris ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 18:01 ` Kris Warkentin @ 2003-07-09 18:05 ` Daniel Jacobowitz 2003-07-09 18:21 ` Kris Warkentin 0 siblings, 1 reply; 21+ messages in thread From: Daniel Jacobowitz @ 2003-07-09 18:05 UTC (permalink / raw) To: Kris Warkentin; +Cc: Kevin Buettner, Andrew Cagney, Gdb@Sources.Redhat.Com On Wed, Jul 09, 2003 at 02:02:00PM -0400, Kris Warkentin wrote: > Someone just pointed something out to me. "set stop-on-solib-events 1" is > NOT enable-load-catchpoint or anything else. Yes, those things should exist > for all solib platforms but the bottom line is that stop-on-solib-events is > not currently mi-enabled and it should be. > > I want to make that command result in proper mi output, regardless of any > other things which might be implemented in the future. And I want load catchpoints fixed, so that stop-on-solib-events is NEVER MI-enabled, so that it can be removed instead of supported for years. It is in every way inferior to catchpoints. That was my point. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 18:05 ` Daniel Jacobowitz @ 2003-07-09 18:21 ` Kris Warkentin 2003-07-09 18:30 ` Daniel Jacobowitz 0 siblings, 1 reply; 21+ messages in thread From: Kris Warkentin @ 2003-07-09 18:21 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Kevin Buettner, Andrew Cagney, Gdb@Sources.Redhat.Com > On Wed, Jul 09, 2003 at 02:02:00PM -0400, Kris Warkentin wrote: > > Someone just pointed something out to me. "set stop-on-solib-events 1" is > > NOT enable-load-catchpoint or anything else. Yes, those things should exist > > for all solib platforms but the bottom line is that stop-on-solib-events is > > not currently mi-enabled and it should be. > > > > I want to make that command result in proper mi output, regardless of any > > other things which might be implemented in the future. > > And I want load catchpoints fixed, so that stop-on-solib-events is > NEVER MI-enabled, so that it can be removed instead of supported for > years. It is in every way inferior to catchpoints. That was my point. Well I want an ice cream bar so I'm going to go get one. :-P Alright then. I see that SOM and PA64 both implement SOLIB_CREATE_CATCH_*LOAD_HOOK and most everyone else just errors out if you try. Should we be adding these functions to the target_so_ops vector? Does every target that supports solibs build solib.c? If so, we could tweak the defines to use the vector and have a default implementation that prints an error. That way solib-svr4 and friends can implement these functions in the backend. ???? Kris ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 18:21 ` Kris Warkentin @ 2003-07-09 18:30 ` Daniel Jacobowitz 2003-07-09 19:12 ` Kris Warkentin 0 siblings, 1 reply; 21+ messages in thread From: Daniel Jacobowitz @ 2003-07-09 18:30 UTC (permalink / raw) To: Kris Warkentin; +Cc: Kevin Buettner, Andrew Cagney, Gdb@Sources.Redhat.Com On Wed, Jul 09, 2003 at 02:21:28PM -0400, Kris Warkentin wrote: > > On Wed, Jul 09, 2003 at 02:02:00PM -0400, Kris Warkentin wrote: > > > Someone just pointed something out to me. "set stop-on-solib-events 1" > is > > > NOT enable-load-catchpoint or anything else. Yes, those things should > exist > > > for all solib platforms but the bottom line is that stop-on-solib-events > is > > > not currently mi-enabled and it should be. > > > > > > I want to make that command result in proper mi output, regardless of > any > > > other things which might be implemented in the future. > > > > And I want load catchpoints fixed, so that stop-on-solib-events is > > NEVER MI-enabled, so that it can be removed instead of supported for > > years. It is in every way inferior to catchpoints. That was my point. > > Well I want an ice cream bar so I'm going to go get one. :-P Curse you, now I want ice cream. > Alright then. I see that SOM and PA64 both implement > SOLIB_CREATE_CATCH_*LOAD_HOOK and most everyone else just errors out if you > try. Should we be adding these functions to the target_so_ops vector? Does > every target that supports solibs build solib.c? If so, we could tweak the > defines to use the vector and have a default implementation that prints an > error. That way solib-svr4 and friends can implement these functions in the > backend. > > ???? That's not really the problem - the breakpoint is already there, it's the same breakpoint we stop at for stop-on-solib-events. The real trick is going to be reporting the events - SOLIB_HAVE_LOAD_EVENT and SOLIB_LOADED_LIBRARY_PATHNAME. The model has to change a little since more than one library can be reported at once in the svr4 model. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 18:30 ` Daniel Jacobowitz @ 2003-07-09 19:12 ` Kris Warkentin 2003-07-09 19:46 ` Daniel Jacobowitz 0 siblings, 1 reply; 21+ messages in thread From: Kris Warkentin @ 2003-07-09 19:12 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Kevin Buettner, Andrew Cagney, Gdb@Sources.Redhat.Com > That's not really the problem - the breakpoint is already there, it's > the same breakpoint we stop at for stop-on-solib-events. The real > trick is going to be reporting the events - SOLIB_HAVE_LOAD_EVENT > and SOLIB_LOADED_LIBRARY_PATHNAME. The model has to change a little > since more than one library can be reported at once in the svr4 model. Well, SOLIB_LOADED_LIBRARY_PATHNAME is only used twice. Once it just fills a string (triggered_dll_pathname) which is only used for printing. Therefore we could return a comma separated list or something pretty like that. The other is just to compare against a dll_pathname so we could get away with creating a SOLIB_WAS_(UN)LOADED(pid, "libname") and have the backend check through the list for libname. Okay...that seems reasonable. Another question: since we've already got a solib breakpoint set in svr4, we don't need to call create_solib_load_event_breakpoint() like somsolib.c and pa64solib.c do. Can you have multiple types associated with a single break or do we just set another at the same address? cheers, Kris ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 19:12 ` Kris Warkentin @ 2003-07-09 19:46 ` Daniel Jacobowitz 2003-07-09 20:00 ` Kris Warkentin 0 siblings, 1 reply; 21+ messages in thread From: Daniel Jacobowitz @ 2003-07-09 19:46 UTC (permalink / raw) To: Kris Warkentin; +Cc: Kevin Buettner, Andrew Cagney, Gdb@Sources.Redhat.Com On Wed, Jul 09, 2003 at 03:13:05PM -0400, Kris Warkentin wrote: > > That's not really the problem - the breakpoint is already there, it's > > the same breakpoint we stop at for stop-on-solib-events. The real > > trick is going to be reporting the events - SOLIB_HAVE_LOAD_EVENT > > and SOLIB_LOADED_LIBRARY_PATHNAME. The model has to change a little > > since more than one library can be reported at once in the svr4 model. > > Well, SOLIB_LOADED_LIBRARY_PATHNAME is only used twice. Once it just fills > a string (triggered_dll_pathname) which is only used for printing. > Therefore we could return a comma separated list or something pretty like > that. > > The other is just to compare against a dll_pathname so we could get away > with creating a SOLIB_WAS_(UN)LOADED(pid, "libname") and have the backend > check through the list for libname. Sure. Or return a list and let solib.c sort between 'em. > Okay...that seems reasonable. Another question: since we've already got a > solib breakpoint set in svr4, we don't need to call > create_solib_load_event_breakpoint() like somsolib.c and pa64solib.c do. > Can you have multiple types associated with a single break or do we just set > another at the same address? It should be multiple "catchpoints", and inserting catchpoints would do nothing to the target. This may require violence to the breakpoint system, which is why I haven't done it yet :( -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 19:46 ` Daniel Jacobowitz @ 2003-07-09 20:00 ` Kris Warkentin 2003-07-09 20:03 ` Daniel Jacobowitz 0 siblings, 1 reply; 21+ messages in thread From: Kris Warkentin @ 2003-07-09 20:00 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Kevin Buettner, Andrew Cagney, Gdb@Sources.Redhat.Com > > The other is just to compare against a dll_pathname so we could get away > > with creating a SOLIB_WAS_(UN)LOADED(pid, "libname") and have the backend > > check through the list for libname. > > Sure. Or return a list and let solib.c sort between 'em. Do you think these functions should be in current_target_so_ops? > > Okay...that seems reasonable. Another question: since we've already got a > > solib breakpoint set in svr4, we don't need to call > > create_solib_load_event_breakpoint() like somsolib.c and pa64solib.c do. > > Can you have multiple types associated with a single break or do we just set > > another at the same address? > > It should be multiple "catchpoints", and inserting catchpoints would do > nothing to the target. This may require violence to the breakpoint > system, which is why I haven't done it yet :( You're suggesting a list of gdb "actions" associated with a single breakpoint on the target? IE, test for a condition, execute a catch, check solibs on the target, etc.? Kris ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 20:00 ` Kris Warkentin @ 2003-07-09 20:03 ` Daniel Jacobowitz 0 siblings, 0 replies; 21+ messages in thread From: Daniel Jacobowitz @ 2003-07-09 20:03 UTC (permalink / raw) To: Kris Warkentin; +Cc: Kevin Buettner, Andrew Cagney, Gdb@Sources.Redhat.Com On Wed, Jul 09, 2003 at 04:00:52PM -0400, Kris Warkentin wrote: > > > The other is just to compare against a dll_pathname so we could get away > > > with creating a SOLIB_WAS_(UN)LOADED(pid, "libname") and have the > backend > > > check through the list for libname. > > > > Sure. Or return a list and let solib.c sort between 'em. > > Do you think these functions should be in current_target_so_ops? Hmm... yes, probably. > > > Okay...that seems reasonable. Another question: since we've already got > a > > > solib breakpoint set in svr4, we don't need to call > > > create_solib_load_event_breakpoint() like somsolib.c and pa64solib.c do. > > > Can you have multiple types associated with a single break or do we just > set > > > another at the same address? > > > > It should be multiple "catchpoints", and inserting catchpoints would do > > nothing to the target. This may require violence to the breakpoint > > system, which is why I haven't done it yet :( > > You're suggesting a list of gdb "actions" associated with a single > breakpoint on the target? IE, test for a condition, execute a catch, check > solibs on the target, etc.? No, a set of catchpoints (type bp_catch_load), one for each condition. But inserting or removing them would do nothing on svr4; the breakpoint is always inserted. When we hit that breakpoint we would check for all catch_load and catch_unloads. This is part of the needed breakpoint overhaul. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 17:49 ` Kris Warkentin 2003-07-09 18:01 ` Kris Warkentin @ 2003-07-18 16:12 ` Andrew Cagney 1 sibling, 0 replies; 21+ messages in thread From: Andrew Cagney @ 2003-07-18 16:12 UTC (permalink / raw) To: Kris Warkentin, Kevin Buettner; +Cc: Daniel Jacobowitz, Gdb@Sources.Redhat.Com >> > > I picked on solib-svr4 because it's the one normally found lacking. > > At > >> > > least one of the solib backends already does this - probably SOM? > >> > >> > So you're saying that you're not receptive to this patch but you'd > > consider > >> > a svr4 patch for the load catchpoints? > >> >> If it could be moved out to solib.c, I'd be receptive to it. I'm also >> willing to look at a patch which modifies solib-svr4.c, but I'd prefer >> one which handles all off the solib backends in one fell swoop. > > > The patch is for breakpoint.c. It's in the print_it_typical() function > which handles output when a breakpoint is hit. I'm not sure how I would put > this into solib.c. It's also for a different problem. MIing a few more stop reasons wouldn't hurt. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-08 20:35 [rfc] Print solib events in mi-mode Kris Warkentin 2003-07-08 21:02 ` Andrew Cagney @ 2003-07-09 20:38 ` Jason Molenda 2003-07-10 12:23 ` Kris Warkentin 2003-07-10 16:33 ` Andrew Cagney 1 sibling, 2 replies; 21+ messages in thread From: Jason Molenda @ 2003-07-09 20:38 UTC (permalink / raw) To: Kris Warkentin; +Cc: Gdb@Sources.Redhat.Com Hi Kris, On Tuesday, July 8, 2003, at 1:36 PM, Kris Warkentin wrote: > What do you think of something like this? When stop-on-solib-events > is set, > this will print the reason as being a shared-lib-event. For what it's worth, at Apple we do something very similar. This section of code in breakpoint.c reads: case bp_shlib_event: /* Did we stop because the user set the stop_on_solib_events variable? (If so, we report this as a generic, "Stopped due to shlib event" message.) */ if (interpreter_p && strncmp (interpreter_p, "mi", 2) == 0) ui_out_field_string (uiout, "reason", "shlib-event"); else printf_filtered ("Stopped due to shared library event\n"); return PRINT_NOTHING; break; For the case where stop-on-shlibs-added is not set, we have an MI notification that gets posted each time a shared library is loaded. It looks like this to the UI side: =shlibs-updated =shlibs-added,shlib-info=[num="54",name="SKTDrawDocument.ob",kind="- ",dyld-addr="0x271000",reason="dyld",requested- state="?",state="N",path="/Developer/Examples/AppKit/Sketch/build/ Sketch.build/Sketch (Upgraded).build/Objects-normal/ppc/ SKTDrawDocument.ob",slide="",addr="",prefix=""] ~"Re-enabling shared library breakpoints: 1\n" <- =shlibs-added,shlib-info=[num="55",name="SKTGraphic.ob",kind="-",dyld- addr="0x28a000",reason="dyld",requested-state="?",state="N",path="/ Developer/Examples/AppKit/Sketch/build/Sketch.build/Sketch (Upgraded).build/Objects-normal/ppc/ SKTGraphic.ob",slide="",addr="",prefix=""] In our case, this message is emitted by one of our arch-specific files, macosx/macosx-nat-dyld.c, in a function called macosx_solib_add(). > Our Eclipse team wants to be able to set breakpoints in shared > libraries > that aren't loaded yet. If they get notification of shlib-events, > then they > can re-examine the list of loaded libraries and set any breakpoints > that > have been enabled in the project's libs. We handled this problem by creating a new breakpoint command, "future-break" (short: "fb", done in MI as "-break-insert -f ..."). This pushes the logic down in to gdb. On the one hand, it's expensive to have gdb trying to set this breakpoint for every shared library that comes in (when you have a lot of big shared libraries like we do on MacOS X), but at the same time if the IDE is responsible for setting breakpoints in shared libraries then you'll have to stop on each solib add event to set those breakpoints before anything runs... You can see all of this in the above sample; breakpoint #1 was a file:line breakpoint, which was in SKTGraphic.ob. When SKTGraphic.ob was paged in (this is a project using ZeroLink, so each source file is a separate objfile, pulled in at run-time as needed), the breakpoint was set by gdb. The future-break patches were posted at least once in the past along with the save-breakpoints command; I can find a URL ref if anyone cares. Jason > > cheers, > > Kris > > $ cvs diff -u breakpoint.c > Index: breakpoint.c > =================================================================== > RCS file: /cvs/src/src/gdb/breakpoint.c,v > retrieving revision 1.125 > diff -u -r1.125 breakpoint.c > --- breakpoint.c 2 Jul 2003 16:24:00 -0000 1.125 > +++ breakpoint.c 8 Jul 2003 20:32:50 -0000 > @@ -2039,8 +2039,10 @@ > /* Did we stop because the user set the stop_on_solib_events > variable? (If so, we report this as a generic, "Stopped due > to shlib event" message.) */ > - printf_filtered ("Stopped due to shared library event\n"); > - return PRINT_NOTHING; > + ui_out_text (uiout, "\nShared library event "); > + if (ui_out_is_mi_like_p (uiout)) > + ui_out_field_string (uiout, "reason", "shared-lib-event"); > + return PRINT_SRC_ONLY; > break; > > case bp_thread_event: > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 20:38 ` Jason Molenda @ 2003-07-10 12:23 ` Kris Warkentin 2003-07-10 16:33 ` Andrew Cagney 1 sibling, 0 replies; 21+ messages in thread From: Kris Warkentin @ 2003-07-10 12:23 UTC (permalink / raw) To: Jason Molenda; +Cc: Gdb@Sources.Redhat.Com > For the case where stop-on-shlibs-added is not set, we have an MI > notification that gets posted each time a shared library is loaded. It > looks like this to the UI side: > > =shlibs-updated > =shlibs-added,shlib-info=[num="54",name="SKTDrawDocument.ob",kind="- > ",dyld-addr="0x271000",reason="dyld",requested- > state="?",state="N",path="/Developer/Examples/AppKit/Sketch/build/ > Sketch.build/Sketch > (Upgraded).build/Objects-normal/ppc/ > SKTDrawDocument.ob",slide="",addr="",prefix=""] > ~"Re-enabling shared library breakpoints: 1\n" > <- > =shlibs-added,shlib-info=[num="55",name="SKTGraphic.ob",kind="-",dyld- > addr="0x28a000",reason="dyld",requested-state="?",state="N",path="/ > Developer/Examples/AppKit/Sketch/build/Sketch.build/Sketch > (Upgraded).build/Objects-normal/ppc/ > SKTGraphic.ob",slide="",addr="",prefix=""] > > > In our case, this message is emitted by one of our arch-specific files, > macosx/macosx-nat-dyld.c, in a function called macosx_solib_add(). Good idea, unfortunately we're mostly using the generic svr4 stuff. I probably COULD do it in our backend but the problem is that this is not QNX specific. It needs to be a standard part of GDB because the Eclipse CDT is going to rely on it. > The future-break patches were posted at least once in the past along > with the save-breakpoints command; I can find a URL ref if anyone > cares. I read that thread. Very interesting. This is one of those cases where it would be nice to have the functionality in gdb but the IDE should be able to do it easier as long as it has notification. It should be fairly easy to get notification from gdb but it doesn't look like Daniel wants people to rely on stop-on-solib-events so he won't let me mi-ificate it. cheers, Kris ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [rfc] Print solib events in mi-mode 2003-07-09 20:38 ` Jason Molenda 2003-07-10 12:23 ` Kris Warkentin @ 2003-07-10 16:33 ` Andrew Cagney 1 sibling, 0 replies; 21+ messages in thread From: Andrew Cagney @ 2003-07-10 16:33 UTC (permalink / raw) To: Jason Molenda; +Cc: Kris Warkentin, Gdb@Sources.Redhat.Com > We handled this problem by creating a new breakpoint command, "future-break" (short: "fb", done in MI as "-break-insert -f ..."). This pushes the logic down in to gdb. On the one hand, it's expensive to have gdb trying to set this breakpoint for every shared library that comes in (when you have a lot of big shared libraries like we do on MacOS X), but at the same time if the IDE is responsible for setting breakpoints in shared libraries then you'll have to stop on each solib add event to set those breakpoints before anything runs... > > You can see all of this in the above sample; breakpoint #1 was a file:line breakpoint, which was in SKTGraphic.ob. When SKTGraphic.ob was paged in (this is a project using ZeroLink, so each source file is a separate objfile, pulled in at run-time as needed), the breakpoint was set by gdb. > > > > The future-break patches were posted at least once in the past along with the save-breakpoints command; I can find a URL ref if anyone cares. Yes, Tom Tromey observed: http://sources.redhat.com/ml/gdb-patches/2001-12/msg00152.html > Klee> The 'future-break' command allows one to specify a breakpoint > Klee> that starts off as 'shlib_disabled' instead of generating an > Klee> error if it can't be set immediately. > > Klee> I'm not entirely happy with the future-break command, and > Klee> particularly with its interaction with the save-breakpoints > Klee> mechanism (if you set a breakpoint that is in a shared library > Klee> after shared libraries have been loaded, you have to remember to > Klee> use the future-break command, not the break command). > > Doesn't this mean that programs like Insight would be best advised to > *only* set future breakpoints? In that case let's just add the > functionality directly to the existing breakpoint commands. enjoy, Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2003-07-18 16:12 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-07-08 20:35 [rfc] Print solib events in mi-mode Kris Warkentin 2003-07-08 21:02 ` Andrew Cagney 2003-07-09 12:24 ` Kris Warkentin 2003-07-09 15:09 ` Daniel Jacobowitz 2003-07-09 15:38 ` Kris Warkentin 2003-07-09 16:24 ` Daniel Jacobowitz 2003-07-09 17:29 ` Kris Warkentin 2003-07-09 17:41 ` Kevin Buettner 2003-07-09 17:49 ` Kris Warkentin 2003-07-09 18:01 ` Kris Warkentin 2003-07-09 18:05 ` Daniel Jacobowitz 2003-07-09 18:21 ` Kris Warkentin 2003-07-09 18:30 ` Daniel Jacobowitz 2003-07-09 19:12 ` Kris Warkentin 2003-07-09 19:46 ` Daniel Jacobowitz 2003-07-09 20:00 ` Kris Warkentin 2003-07-09 20:03 ` Daniel Jacobowitz 2003-07-18 16:12 ` Andrew Cagney 2003-07-09 20:38 ` Jason Molenda 2003-07-10 12:23 ` Kris Warkentin 2003-07-10 16:33 ` Andrew Cagney
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).