Community
Participate
Working Groups
As per summary, it still seems to be impossible to do this from the users perspective. I've looked around generally, e.g. Google, and specifically in the Eclipse Bugzilla & newgroups and the only real reference I can see is http://dev.eclipse.org/newslists/news.eclipse.tools.cdt/msg07122.html and a couple of references to the Zylin plugin. In addition to the plugin, (which not really a solution) the first reference gives possible work-arounds of - expand binary in the Debug pane (which is having no effect on Europa Version: 3.3.0, Build id: I20070621-1340 on Ubuntu 6.10/x86) and select the function you require.. this is may work with trivial application but is hardly a solution (even should it work) - type the break point command directly into the GDB console.. which also appears not to work in as much as the text can be entered into the console (and return key presses registered) but GDB takes no notice of it (not passed through ?). This, too, seems a little bit of a kludge, albeit on a significantly smaller scale. A quick look at the breakpoint API hasn't revealed much of use yet.. mainly because i'm still trying to un-ravel the language used in the class spec (which probably makes perfect sense if you live in the Eclipse internals but somewhat baroque to the outside eye - full of details specifying nothing that can be traced from the context). I'll keep digging on that... The original poster of the 2005 query mentioned that they'd file an enhancement request but I can't find one.. i'd like to raise one now though. I've got to confess, i'm absolutely stunned that this hasn't been raised more - it's incredibly basic functionality, but one that is used widely (especially when debugging a stand-alone executable rather than project based). Cheers t
You can set a function/method breakpoint from the outline view or in the editor using "Run/Toggle method breakpoint". If you have problems setting a breakpoint from the gdb console, please file a bug with a test case.
(In reply to comment #1) Thanks for the quick reply Mikhail. > You can set a function/method breakpoint from the outline view This only makes possible setting breakpoints within the currently opened file which, while occassionally convenient, is not that useful for non-trivial application structures (it gains some usability once you have all the relevent files open but you have a bit of a chicken and egg situation there). >or in the editor > using "Run/Toggle method breakpoint". My apologies, I completely missed this for some reason, and I did not see it mentioned in the help - the menu system for the breakpoint setting methods is non mentioned in the 'Adding Breakpoints' section or it's references - if this is not expected i'll file a separate ticket for this. All that aside, 'Toggle Method Breakpoint' does not provide a method to set a breakpoint by name anyway, AFAICS. Trying to set while broken in a arbitrary code segment (e.g. main()) is either not possible as (a) the menu item is not available (seems to be triggered on the initial breakpoint set only, i'm going to try and get a simple set of operations to reproduce later) or, (b) when the menu item IS available, selecting it prompts a dialog to be launched which says 'The operation is unavailable in the current selection. Please place the cursor inside a method' .. this would seem to imply that the source file must be opened before a breakpoint can be set on method, and then it would seem that the breakpoint is set by context (in this case, the cursor existing within the declaration of the method) and NOT by name. That can't be right surely ? > If you have problems setting a breakpoint from the gdb console, please file a > bug with a test case. Fair enough - I'll re-file as a seperate issue. Cheers
Setting a function breakpoint by name only doesn't work very well in Eclipse. Breakpoints in Eclipse are shared by all running debug sessions. It's a responsibilty of the session to filter out the breakpoints that do not "belong" to it. If a breakpoint is attached to a source file or an executable it's a relatively simple check. Otherwise, the session will try to set the breakpoint. So, if you have a breakpoint at "func" it will be set to all debug sessions that contain the "func" function regardless whether you want it or not. Same applies to the address breakpoints.
(In reply to comment #3) > Setting a function breakpoint by name only doesn't work very well in Eclipse. > Breakpoints in Eclipse are shared by all running debug sessions. You're kidding right ?... all running debug sessions ?... even if the application is different in each one ? That is perverse, but at least usable in a single session with a single user IF the user could set the breakpoint by name in the first place... but I still can't see any way of doing that. Am I still missing something ? > It's a > responsibilty of the session to filter out the breakpoints that do not "belong" > to it. Hmmmmm.. pardon me saying but isn't that completely arse backwards ? > If a breakpoint is attached to a source file or an executable it's a > relatively simple check. Otherwise, the session will try to set the breakpoint. Where is the session trying to 'set' the breakpoint ? Surely if I set a breakpoint in session 'A' then it is 'for' session A, not B or C or D. Even if the breakpoints are keep globally (weird and extra work i'd have thought) then I presume they are at least constructed with knowledge of the session they derived from. What happens to breakpoints set in a file that is shared amongst debug sessions (e.g. source code from a library linked, statically or dynamically, into the applications).. are these shared amongst all sesssions too ? > So, if you have a breakpoint at "func" it will be set to all debug sessions > that contain the "func" function regardless whether you want it or not. > Same > applies to the address breakpoints. > How is the breakpoint actually set then ? Is there some global state or thread with the bp information in ? Is there any documentation I can look at that would help here ? Shall I mark this as a LATER or WONTFIX for now ? Doesn't sound like any work arounds are available to make it usable in the real world for now alas... I understand that the focus of Eclipse/CDT was not as a stand-alone debugger but it's a pity.. Thanks for your time Mikhail Cheers
You don't set a breakpoint on a session, you set it on a line, address or name. You can do it with or without a running session. If there is a session running at the moment when the breakpoint is set, it gets a notification from the breakpoint manager that a breakpoint is added. It is up to the session to decide what to do with it. If a new session is started it requests from the breakpoint manager ALL breakpoints set at that moment in Eclipse and it is up to the session to filter the breakpoints and try to set them. I would suggest to leave the request as it is. We can add an action to set a breakpoint on an arbitrary expression and leave it up to users to decide whether they want to use it or not.
True, but I think this kind of breakpoint filtering is one of the features we'll need to do for the next release. Even if we could do something like specify which launch configs a breakpoint applies to.
Filtering of breakpoints would certainly be a good future development, given the existing architectural limitations, but before that it would useful (i.e. fairly useless without) to be able to *set* breakpoints by name. Any thoughts on whether that is likely ? Perhaps i've mis-interpreted the idea of "session" in this context.. if I set a method breakpoint while debugging an executable - what is that breakpoint associated with ? e.g. If I start another eclipse framework up, and start debugging another executable with shared code, does it inherit the breakpoint ? What happens if the executables are the same ?
Doug, the issue of filtering (or assignment) is of particular interest in the homogeneous multicore world. You may debugging two ARM cores running the same program code . You want to set a breakpoint in foo.cpp line 10 but only have it be applied to one core. Right now, I know of no way to do this. In general, there are a lot of limitations with breakpoints that surface when you move out of the simple scenarios and into the multicore world. I strongly suspect the PTP project isn't using the platform breakpoint support :-)
BTW, I realize that you can do this kind of filtering once the breakpoint is set, by going into the properties page, but I'm referring to being able to set that intent from the outset. Have, for example, a mode where, when active, a breakpoint is set only the active debug session.
(In reply to comment #9) > BTW, I realize that you can do this kind of filtering once the breakpoint is > set, by going into the properties page, but I'm referring to being able to set > that intent from the outset. Have, for example, a mode where, when active, a > breakpoint is set only the active debug session. Yes, this is all good stuff. These kind of issues need to be addressed and I'd like to see them on the table for Ganymede (CDT'08).
(In reply to comment #7) > Filtering of breakpoints would certainly be a good future development, given > the existing architectural limitations, but before that it would useful (i.e. > fairly useless without) to be able to *set* breakpoints by name. Any thoughts > on whether that is likely ? > Perhaps i've mis-interpreted the idea of "session" in this context.. if I set a > method breakpoint while debugging an executable - what is that breakpoint > associated with ? e.g. If I start another eclipse framework up, and start > debugging another executable with shared code, does it inherit the breakpoint ? > What happens if the executables are the same ? You can debug as many executables as you want in the same Eclipse workbench. You can debug Java programs and C programs at the same.
(In reply to comment #11) [snip] > You can debug as many executables as you want in the same Eclipse workbench. > You can debug Java programs and C programs at the same. Yep, i'm aware of that.. I was asking what the scope of breakpoints were. So far, as far I can tell from usage and these replies, there is no way to breakpoints prior to the source file in which you to set being loaded, e.g. you cannot set by function/method name or file/line-number in general. In addition, breakpoints are global to 'sessions' but there doesn't appear to be any definition of 'session' - please, what scope do breakpoints have and what is the intended meaning of 'session' in this context ?
(In reply to comment #12) Breakpoint usually is associated with a project via the source file or executable it is set on. When you launch the debugger you specify an executable and the project the executable belongs to. You can add references to other projects and add directories to the source search path (see the "Source" page of the launch configuration dialog). This defines the scope of the breakpoint: if the file breakpoint is assiciated with is not in the source path the breakpoint is filtered out.
Mikhail, I think the filtering out of breakpoints in files not in the launch config's collective source path was effectively disabled by Nokia in order to support various scenarios where this proved too limiting. I believe it was part of the work to support debugging executables not built by an Eclipse project. I'm going on memory here. Perhaps Ken can confirm this. We do however filter out based on file type. So, e.g., when setting a breakpoint in a .java file, there won't be an attempt to set it in a CDebugTarget.
(In reply to comment #14) John, I have just checked it and the filtering is still there (CBreakpointManager::isTargetBreakpoint). Also we filter out all breakpoints that are not CBreakpoints.
On the surface, the filtering is there, but the underlying logic in CSourceLookupDirector.java changed. See bugzilla 182133.
I think any filtering of breakpoints should be done based on the properties of the breakpoint. So if you want a breakpoint to only apply to a specific process/thread/core/ etc. that can just be a property that the back-end can respect. If you want the user experience to be that breakpoints by default apply to only a specific context then we can make that happen by setting the default properties appropriately. The change I made that John is referring to was to add a default absolute path source locator so that breakpoints with locations in valid file paths were always "found" and sent to the back-end.
(In reply to comment #17) > I think any filtering of breakpoints should be done based on the properties of > the breakpoint. So if you want a breakpoint to only apply to a specific > process/thread/core/ etc. that can just be a property that the back-end can > respect. If you want the user experience to be that breakpoints by default > apply to only a specific context then we can make that happen by setting the > default properties appropriately. Argee, but how do you specify a context that hasn't been created yet?
So much traffic on this bug, I think I have to join the fun. Breakpiont scope/filtering has been a big pain point in our (Wind River's) debugger. Our solution was to allow the user to define a breakpoint scope that restricted it to a set of launch configurations. This works in most cases but in some cases it is confusing and insufficient. To improve on that, I thought it would be best to define a new type of breakpoint grouping that is similar or as an extension to breakpoint working sets. Then define the breakpoint filter properties at this group level. Unfortunately, I haven't even had a chance to prototype this solution.
This bug was assigned and targeted at a now released milestone (or Future or Next that isn't being used by CDT). As that milestone has now passed, the milestone field has been cleared. If this bug has been fixed, please set the milestone to the version it was fixed in and mark the bug as resolved.
