This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 163524

Summary: Need API to bind a specific debugger to a toolchain
Product: cnd Reporter: _ gordonp <gordonp>
Component: ToolchainAssignee: Alexander Simon <alexvsimon>
Status: NEW ---    
Severity: blocker CC: vincesheard
Priority: P2    
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on:    
Bug Blocks: 151788    

Description _ gordonp 2009-04-23 19:48:05 UTC
MC binaries are not debuggable with gdb. Sun Studio C++ binaries also
don't debug well with gdb. Furthermore, it makes sense for Sun Studio
compiled code to default to a dbx debugger module (if available) and
GNU compiled code to default to the gdb debugger module.

This enhancement proposes the following:
    1. The toolchain descriptor implementation gets 2 more fields,
       preferredDebugger and requiredDebugger fields. A required
       debugger will *always* be used. If there is no required debugger,
       a preferred one overrides any others. If there is neither a
       preferred nor required debugger then any debugger handling the
       specified language is acceptable.

    2. The ProjectActionSupport$HandleEvents.go method has a loop at its
       end which chooses an action handler factory. This loop should be
       rewritten such that for the DEBUG action the above properties are
       used.

    3. The GNU.xml toolchain descriptor should be have a preferred debugger
       of "org.netbeans.modules.cnd.debugger.gdb.actions.GdbActionHandlerFactory".

    4. The sunstudio.xml toolchain descriptor should have a preferred debugger of
       "com.sun.sunstudio.<...>.DbxGuiActionHandlerFactory" (probably not the
       correct name, but you get the picture...)

Although filed on behalf of MC, this suggested solution resolves issues between
cnd's gdb module and Sun Studio's dbxgui modules.

I have a complete implementation of this proposed fix and will attach it to the
issue. It should be safe to implement *after* NetBeans 6.7 code freeze when the
trunk is opened up to post 6.7 work.
Comment 1 _ gordonp 2009-04-23 19:49:13 UTC
Note: MC would prefer this be implemented in a NB 6.7 patch, if possible.
Comment 2 _ gordonp 2009-04-24 01:04:42 UTC
> I have a complete implementation of this proposed fix and will attach it to the
> issue

My fix is in a slightly modified NB6.7 tree. If you are in no hurry I'll eventually
put it into a trunk derived tree which would isolate the changes better (and make it
more likely to successfully import). Let me know what you want (and when).
Comment 3 Thomas Preisler 2009-04-24 01:08:37 UTC
please wait until after 6.7. I will let you know when we are ready.
Comment 4 Thomas Preisler 2009-10-23 03:42:43 UTC
Reassigning to Egor. He is currently working on it now for 68.