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.
The Discovery wizard/process required projects get built with -g3 -gdwarf-2. On the Mac, this produces an executable which isn't debuggable. Recompiling with -g produces a debuggable exe. To reproduce with quote: 1. Compile with -g3 -gdwarf-2 (the default flags). 2. Run gdb (from the command line) on the exe 3. Set a breakpoint at lines 104 ("fetchCustomerList()" in main) and 57 ("if ((*it).GetName() == name) {" in getDiscountFor(). (Note: These line numbers are pre CDDL/gpl header change so you'll have to adjust if you create a new quote app). 4. Run to the 1st breakpoint ("run" command). Note that you've stopped on line 102 and the message says it breakpoint 2 5. Run to the 2nd breakpoint ("continue" command) It correctly says its breakpoint 1 and line 104. Here is the output of my run: $ gdb -q dist/Debug/GNU-MacOSX/quote_1 Reading symbols for shared libraries .... done (gdb) b 104 Breakpoint 1 at 0x3c30: file quote.cc, line 104. (gdb) b 57 Breakpoint 2 at 0x3bea: file quote.cc, line 57. (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x00003c30 in main at quote.cc:104 2 breakpoint keep y 0x00003bea in main at quote.cc:57 (gdb) run Starting program: /Users/gordonp/NetBeansProjects/Quote_1/dist/Debug/GNU-MacOSX/quote_1 Reading symbols for shared libraries . done Breakpoint 2, main (argc=1, argv=0xbffffb54) at quote.cc:102 102 cout << "Support metric quote program" << endl << endl; (gdb) continue Continuing. Support metric quote program Breakpoint 1, main (argc=1, argv=0xbffffb54) at quote.cc:104 104 fetchCustomersList(); (gdb) kill Kill the program being debugged? (y or n) y (gdb) quit $
I think that methods GNUCCCompiler.getDevelopmentModeOptions() and GNUCCompiler.getDevelopmentModeOptions() should return platform dependent compiler flags. It seems for Mac it should be "-g".
Jesse asked me to file this bug because he wants the discovery system to process Mach-O debug information. Concurrently, Thomas will be changing the flags generated on the Mac. I believe Thomas is looking to you for a recommendation as to what debug flags he should use (just -g or -g3 or ???).
yes, just let me know what compiler option I should generate. Alexander, the problem is if we generate -g the discovery wizard doesn't work and we we generate -g3 -gdwarf-2 gdb doesn't work well. Can the discovery wizard be changed to understand -g generated debug information?
In thee "GCC 4.0 Release Notes" on web page: http://developer.apple.com/releasenotes/DeveloperTools/RN-GCC4/index.html you can see following note about DWARF: DWARF debugging format is now supported. However, STABS is still used as default debugging format. In subsequent releases, DWARF will be used as default debugging format.
I checked different combination of debug flags. This is a list of flags that produce debug information for discovery wizard: -g3 -gdwarf-2 -g -gdwarf-2 -gdwarf-2 This is a list of flags that do not produce debug information for discovery wizard: -g -g3 This is a list of flags that do not allowed by compiler: -g3 -gstabs -gdwarf-2 -g3 -gdwarf-2 -gstabs
In the release notes for xcode: http://developer.apple.com/tools/xcode/newinxcode23.html the developer has a UI facility for selecting either stabs or dwarf as the debugging commentary. It seems likely (from other developer notes) that choosing dwarf in xcode sets the compiler option -ggdb. We can confirm the actual setting by generating an executable with xcode and the UI dwarf option selected.
A command line only check was positive. I build quote with -g3 -ggdb and could debug it (I didn't do more than sanity test it, though, but that failed with -gdwarf-2).
Flags "-g3 -ggdb -gdwarf-2" produce debug information for discovery wizard. Flags "-g3 -ggdb" do not.
The debug session in my original entry still fail with "-g3 -ggdb -gdwarf-2".
Look at: http://developer.apple.com/releasenotes/DeveloperTools/RN-GDB/index.html My understanding is that striping debug information from executable can fix problem. i.e. 1. compile flags is "-g3 -ggdb -gdwarf-2" 2. linker strip debug information from executable.
How will stripping debug information help make something more debuggable? If there is a partial strip which removes the -gdwarf-2 stuff but leaves the -ggdb stuff intact (and leaves the exectable debuggable) then this approach would work. Otherwise it would not. I tried building with "-g3 -ggdb -gdwarf-2" and linking with -Wl,-Sp. Still couldn't debug. I can't imagine the other strip options are as likely to work as this one...
Could you try strip in way described in the section "Changes since Xcode 2.2 Developer tools update (gdb-437)" on http://developer.apple.com/releasenotes/DeveloperTools/RN-GDB/index.html
"gdb-437" refers to a way of getting the debug information in a separate file so a stripped version can be used. Then you can debug the striped exe by adding the dSYM file at debug time. That doesn't apply here because the debug information in the dSYM file would be identical to the original debug information in the executable and .o files. In other words, it would have both the output of -ggdb and -gdwarf-2 in the dSYM file.
Options we discuss here are relevant for *managed* projects only. In contrary, the discovery system only works (and makes sense) with makefile-based projects. So I believe it's worth just changing default options to -g. (Moreover, I would propose to change it independently of OS). We still have an issue regarding how to advise Mac user on building/configuring makefile projects and using discovery system. But anyhow, I believe this discussion is beyond this IZ.
OK, Iwill change it back to -g for GNU compilers on all platforms.
*** Issue 116354 has been marked as a duplicate of this issue. ***
As resolved for beta 2 (with -g) debugging works properly (with stabs). Language model discovery (which benefits from having dwarf) is limited. The user has a workaround -- explicitly compiling with dwarf during initial project discovery, and then explicitly compiling with stabs for debugging. We need a better solution, and we'll re-examine with Leopard later this month. The defect is downgraded to P2.
Summary table of dwarf information: flag | Dwarf information --------------------+-------------------------- -g | not found dwarf -g3 | not found dwarf -g3 -ggdb | not found dwarf -g -gdwarf-2 | include paths -gdwarf-2 | include paths -ggdb | include paths -g3 -gdwarf-2 | macros and include paths -g3 -ggdb- gdwarf-2 | macros and include paths --------------------+--------------------------
Downgraded to a P3.
Summary table of dwarf information for Leopard: flag | Dwarf information --------------------+-------------------------- -g | include paths (not full set of included files) -g3 | macros and include paths -g3 -ggdb | macros and include paths -g -gdwarf-2 | include paths (not full set of included files) -gdwarf-2 | include paths (not full set of included files) -ggdb | include paths (not full set of included files) -g3 -gdwarf-2 | macros and include paths -g3 -ggdb- gdwarf-2 | macros and include paths --------------------+--------------------------
This is no longer an issue with new release (Leopard) of Mac OS.