Netbeans 7.01 with Cygwin, debugger won't stop on breakpoints - netbeans

I presume that the debugger is configured correctly (but what else can it be)?
If I look at Tools/Options/C/C++ it is set up nicely for Cygwin_4.x and the toolset programs all exist (especially C:\cygwin\bin\gdb.exe) Since I can build and link ok, and this all gets setup by NetBeans discovery of the toolset, I would expect to be able to debug.
The only minor detail is that C:\users\mawg.gdbinit does not exist. I supplied an empty file to no avail. IIRC from form running GDB by hand 20 years ago it isn't necessary.
If I Ctrl+F5 (debug main project (I have only one)) or Alt+F6 (run all test files) the application runs and produces output ... I can also "step into" and proceed with F7 & F8 ...
... but it won't stop on breakpoints.
I guess that I am missing something very simple. Who can point it out to me, please? Thanks

OK, I could just delete this question, but I will post the "answer" just so others might have one more thing to check if they have the same problem.
Not being able to debug with Netbans, I tried MS visual studio and it reported that I had an opening
#ifdef __cplusplus
extern "C" {
#endif
without the corresponding close.
This is not a NetBeans problem; it is a GCC compiler problem, from GCC of Cygwin, I will report this to GNU/GCC.
Moral: migh be worth checking; but it is always worth running problematic code through a few different compilers and linters.

Related

Net Beans "Must set src.dir" error when generating jforms

I have developed a problem, I cannot resolve.
I am running Net Bean 8.2 Build: 201609300101.
I am running it on a Windows 7 platform.
Yesterday Net Bean worked fine and would generate the jforms for me. Last night something happened and I can no-longer build, compile and run jforms classes.
I can generate and run simple Java programs. I wrote a simple program that just prints "Hello" and that worked.
When I generate a jform, everything looks good in the IDE but it will not build or run.
I get the following error:
c:users\Admin\Documents\Netbeans\KensPanel\nbproject\build-impl.xml:899 Must set src.dir.
None of the NetBeans examples work either and they did yesterday.
In reviewing the posts on the NetBeans forum concerning the problem, I found several that suggested looking in "nbproject directory for a project.properties file. in the file there should be a "build.dir = build" statement. It is there.
I have completely deleted the project and rebuilt the program and that did not work.
I uninstalled the NetBeans program, the JDK and the JRE programs and reinstalled them (JDK & JRE first) and that did not fix the problem.
I put a simple print statement "(System.out.println("Hello");" in the "Public Static void Main(String[] args)" function at the bottom of the KensPanel.java file and the program will compile and print out "Hello" but will not bring up the GUI.
I get the feeling the problem is somehow related to the "ANT" process but anything having anything to do with that is way over my head.
As I stated earlier, the program worked yesterday afternoon. Last night, the IDE decided that it did not want to play any more and I have not been able to find the problem. I am at a loss.
I am real new to the program and for that matter, Java in general. I really need help.
Ken
I think I found my own answer. At least, I got around the problem.
In the New Java application screen, I had left the "create Main Class" box checked. I found in the NetBeans tutorial, the tutorial stated that I needed to "un-check" the box. When I did that, at least my application works. I haven't tried the examples yet.
Moving on to the next learning task.
Ken

How to run my code on an ARM _without_ debugging?

I've been developing a project (in C) for an STM32F105, using the Eclipse IDE with CDT plugins. I'm using the gcc-arm toolchain, OpenOCD (gdb) for debugging, and an ST-Link/V2 JTAG device.
I've been debugging on my target board, no problems.
Now, I finally want the code to run by itself, and I don't know how to do it in Eclipse! I'm sure it's simple, but I can't find it.
How do I build the code and program my target so that it runs "normally"?
Configure OpenOCD as external tool and use arguments more or less like these:
-f interface/... -f target/... -c "init; reset init; flash write_image erase <your_hex_file.hex>; reset run; shutdown;"
You should of course adapt this command to your project: enter proper interface and target configs and set right name of hex file (you can also use .bin or .elf, but .hex is usually the most convenient).
In the "Working Directory" textbox enter your project directory - use "Browse Workspace" to do that, you should have sth like this there: ${workspace_loc:/<name_of_your_project>}
One of my projects worked by simply disconnecting the debugger and resetting the target, as suggested by #ChrisStratton. The other didn't, whether I used the IDE or the ST-LINK tools. It worked fine when the debugger was attached.
It turns out that the non-working program was using semi-hosting. When I disabled semi-hosting by removing the following compiler symbols, the project started running just fine on its own.

How to debug Eclipse's internal clases

I have a very strange problem with regards to contributing to Eclipse. I have modified bundle org.eclipse.jdt.internal.junit4.runner and just wanted to test it and try it, but for some strange reason my breakpoints in the bundle org.eclipse.jdt.internal.junit4.runner are not working. It sounds to me that there is an internal filtering that cause that these bundles are ignored for breakpoint.
Funny thing is when I add
System.err.println("Did you reach it?"); //$NON-NLS-1$
In the console I can see the text, but the breakpoint is not working...
Any advice would be very welcome.
Look here. Also check whether any packages are excluded in Windows->Preferences->Java->Debug->Step filtering.
Well, I found out the problem but not a complete answer.
The problem is especially related to the org.eclipse.jdt.internal.junit4.runner bundle which launches and an another virtual machine and the code within this VM is not in debug mode, e.g. the first virtual machine is in debug mode and the second is not and that was the reason why my breakpoints did not work. So I guess there is no possibility how to enable debug mode "by eclipse automatically" in the subsequent VMs.
Here is an example of 2 VM from my blog http://blog.chocolatejar.eu/contribution/2014/02/27/better-visualization-junit-failures/

Debugging STMF4 Discovery in Eclipse using GDB

Hello all: I have never posted on Stackoverflow, but I have always come here for help for years.
I have a question and problem regarding debugging in eclipse using an STLINK STM32 Discovery board. I have looked online for the answer and have followed many tutorials, but I still cannot seem to get it to work correctly. I will try my luck at asking here.
I have set up the eclipse environment correctly with my compiler and gdb server (to my knowledge). First I make sure the server is started before I press debug in eclipse. I am using Atollic STLINK gdb server. I have tried many arm-none-eabi-gdb type exe's while debugging, but they all seem the same. My debug configuration is setup to use arm-none-eabi-gdb on port 61234 (Attolic). When I press debug, the program launches correctly and goes into the debug view in eclipse. The program downloads correctly to my discovery board. I know this because I have gotten debugging to work partially and have stepped through the code without crashing on 'some' occasions depending on the compiled code and debug configuration startup options. The code is a simple LED turn on on the board. If I unplug the usb cable and plug it back in, my code runs fine, because the LEDs light up, so we know the environment is probably set up correctly, because the code downloads to flash via eclipse commands.
The problem is with actual debug steps. 99% of the time the arm-none-eabi-gdb.exe program crashes when in the debug view after I do a few "step into's" with the debugger commands at the top of eclipse. After the first line of my main function is reached, I will try to step into the first line and I get a windows crash of the arm-eabi.exe program. The debug console in eclipse reads a gdb error: .......dwarf2: C10xx Internal Error - unknown CFA rule. Now... depending on how I set the options in the debug configuration with regards to the startup tab, different options produce different results and the following options have been toggled: Halt, resume, break point at : main, etc.. This crash also seems to be dependent on the code being compiled in the main function.
Now, does this have any dependency on which compiler is used with the gdb server and arm-none-eabi-gdb.exe programs? For instance, if I compiled the code with Atollic versus Keil versus code sourcery versus IAR, would the Attollic gdb service + arm-none-eabi-gdb programs be able to work with any compiled code? Are there some missing symbols somewhere not being generated? For reference, I am using an EVAL version of the IAR compiler tool set. If I make a project with the same code in embedded workbench using the STLINK, the code compiles and debugs fine.
What is a CFA rule? Call frame address? Am I not setting up the stack pointer or something in my program? I thought the IAR compiler took care of all that junk in the cstartup.
Any help is appreciated.
Thanks,
LostTime77

Is is possible to compile projects with "IDE-Managed Components" through the command line?

I've been trying to build some huge projects in BCB5 for some time now. I want to use the command line tools because it would cut build time by more than 50% (it already takes 4 hours in the IDE). Often, projects will build just fine in the IDE but fail miserably in the command line. I did some digging and discovered this nice little comment in a header file:
__published: // IDE-managed Components
Is this saying that the components that follow can only be built with the IDE open? Please tell me there is a way around this. BCB5 is starting to make me depressed.
Extra info:
Make.exe gives a pile of errors claiming ambiguity between the header file and an imported file. I''m pretty sure the header file is supposed to be referencing the imported file though, rather than comparing with it.
In the header file:
#include <ComCtrls.hpp>
ComCtrls.hpp has the variable TTreeNode.
Error from make:
[exec] Error E2015 .\TMain.h 876: Ambiguity between 'TTreeNode' and 'Comctrls::TTreeNode'
__published: // IDE-managed Components Is this saying that the
components that follow can only be
built with the IDE open? Please tell
me there is a way around this. BCB5 is
starting to make me depressed.
No, this does not mean that you can only build the source in the IDE. It just means that this section is automatically populated by the IDE (the form designer)
While there are good third party solutions (as mentioned by the others) C++Builder 2007 and above made huge improvements in the build system. IDE build times are very similar to command line builds and the MSBuild integration now makes it possible to be sure that the same parameters are passed to the command line tools as are used by the IDE.
Have you tried installing the C++ Compiler Enhancements plugin, by Andreas Hausladen, which improves the compilation speed. I would also recommend installing the DelphiSpeedUp plugin.
I think you need to export the project as makefile, to compile from the command line, because C++Builder 5 project files are XML. Have a look at this article, from the C++Builder Developer's Journal.
If none of the above fails try the official C++Builder Forum.
I've more or less given up on the BCB5 command line tools. It appears that they are fundamentally broken.
I did, however, manage to find a nice open source tool, ProjectMaker, that uses the command line tools effectively. You can find it here: http://projectmaker.jomitech.com.
ProjectMaker fixes up a few of the problems with BPR2MAK, but it's not perfect. Most project build perfectly with ProjectMaker, some still require the IDE. It's not a perfect solution, but it does alright.