Bug 163524 - Need API to bind a specific debugger to a toolchain
Need API to bind a specific debugger to a toolchain
Status: NEW
Product: cnd
Classification: Unclassified
Component: Toolchain
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Alexander Simon
issues@cnd
MC
:
Depends on:
Blocks: 151788
  Show dependency treegraph
 
Reported: 2009-04-23 19:48 UTC by _ gordonp
Modified: 2010-04-25 09:24 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo