Debugging Zos cobol with RDz - debugging

My intetion is to debug the called cobol program aswel.
But not sure how to keep a break point to go inside the called cobol program.
At the moment i am able to debugg the main cobol program and control just goes over the called copbol program.Thanks

Considering that it is Cobol on a Mainframe and that you already accessed the debugger, I guess the issue is with the compilation of the called program.
Usually, programs that are called by a program in debugger are jumped over (they run, but you can't see code or control them) if you forget to compile the called program with debugger option.
The same way you compiled your program with DEBUG option, you can compile the called program. This usually is done with a 'D' option at the compilation screen.
Let me know if this works.

Are you building the called subprogram in the same RD/z project? That can make a difference. Otherwise, you will need to use the mainframe side of things to point your debug info back at your workstaions IP address either via the LE TEST() parameter on the parm string or by linking in a custom CEEINIT to specify those parms.

Related

when does the compiler compile the code into machine code?

As far as I know, the compiler compiles the code by converting it to a language that a computer can understand which is the machine language and this is done before running the code.
So, does the compiler compile my code each time I write a character in the file?
And if so, does it check the whole code? Or just the line that updated.
An important part to this question is the type of programming language(PL) we are talking about. Generally speaking, I would categorize PL into 3 groups:
Traditional PLs. Ex: C, C++, Rust
The compiler compiles the code into machine language when you hit the "build" button or the "run" button.
It doesn't compile every time you change the code, but a code linter does continuously observe your code and check it for errors.
Another note, when you change part of the code and compile it, the compiler doesn't recompile everything. It usually only recompile the current assembly file (or module or whatever you call them).
It is also important to note that a lot of modern IDEs, compile when you save the files.
There is also the hot reload feature. It is a smart compiler feature that can swap certain parts of the code while it is running.
Interpreted PLs Ex: python, JS and PHP
Those languages never get compiled; Rather, they get interpreted or translated into native code on the fly and in-memory when you run them.
Those languages usually employee a cache to accelerate the subsequent code execution.
Intermediary Code PL. Ex: Kotlin, java, C#
Have 2 stages of compilation:
Build time compilation.
Just in time (run-time) compilation.
Build time compilation converts the code into intermediary language (IL) machine code, which is special to the run-time.
This code only understood by the run time like Java runtime or dot net runtime
The second compilation happens when the programs get installed or ran for the first time. This is called just in time compilation (JIT)
The run-time convert the code into native code specific to the run-time OS.

Run cpp file without compiling

How to directly run a c++ file present in read-only storage like CD-drive without making executable files using g++? There must be some arguments for that to work.
The process of a C/C++ program when you make one till you run it:
You write the program's source code.
The compiler comes in here and compiles the source code to object files.
Note: Remember that the program cannot be executed at this stage. It's only an object file. You'd know this if you have worked on bigger size programs, but if you haven't here is how it works. Remember using those header files in your programs? These header files just tell the compiler that there are some things that are not defined in your program. They are somewhere else. So your compile compiles the program to the object file leaving out things that have a prototype (which is in the header files).
This is a very important point. Here a program called 'linker' comes into play. What linker does is to take all the object files created by compiler and combines them into one. Say for example your compiler created a single object file. Now, you're using math library or anything from standard library. The compiler-linker package (often called only compiler) comes with object files for these standard library definitions. So, linker takes your object file and combines it with other object files from the package and then converts it to an executable file. This is the file that you can run. Nothing else is runnable directly.
To run source code the process is explained already, we have to use the g++. Now
What I understand from your question is that you want to know if a program can be run once it's compiled and linked properly (hence an executable has been generated). Answer to that would be yes.
Alternatively, may sound strange, there is an interpreter I know called Cling that can be of use to bypass the compilation of C++ program.
After all C++ is generally seen as a compiled language. However, any programming language can be implemented as a compiler or as an interpreter and Cling happens to be an interactive C++ interpreter based on LLVM and Clang.
Take a thorough look at this

AOSP lldbclient.py missing?

I'm building AOSP from source and have created a small C++ program that prints some messages to logcat when started. Now I wanted to debug the program according to https://source.android.com/devices/tech/debug/gdb
In the reference you're encouraged to use lldb in favor of gdb and there is also a short section on using vs code as debugger.
However, I cannot find the mentioned script lldbclient anywhere in my source nor in Android Code Search, only gdbclient.py seems to be present.
Q1: Where can I find lldbclient script?
When running the gdbclient.py script the option --setup-forwarding vscode seems to be ignored and gdb is always started.
Q2: If there isn't a lldbclient script, what options do I have to pass to gdbclient.py to enable debugging with lldb and vs code?
What did I do so far?
gdbclient.py -r /data/mysample_bin --setup-forwarding vscode
Starts my native program with attached gdb and allows me to step through my program.
Though I do not know how to code python, I was able to track down a call sequence in the script to method generate_setup_script, which is called with parameter debugger=gdb. Therefore no lldb configuration for vs code is created. Passing --no-gdb or --lldb to the script doesn't change this behavior.
Q1: You can find lldbclient.py script in the repository https://android.googlesource.com/platform/development, branch android-s-beta-2 (or another android-s branch).
Q2: Android also provides some tutorial debugging with Vscode: https://source.android.com/devices/tech/debug/gdb#vscode.

Debugging a Hotspot VM in Netbeans

I built a (customized) 1.8 HotSpot VM in Netbeans 7.2 using GDB 7.4 which works for executing Java programs. I want to debug a SIGSEGV that the program produces by calling a native function called by JNI that corrupts an object header.
However, I have some problems debugging the HotSpot VM: I have several breakpoints before the call to the main function in java.c. Sometimes, they trigger and sometimes the main function executes without all the breakpoints halting before. The most far I can get is
/* Invoke main method. */
(*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs);
After that, a step-in runs through the whole Java program, eventually triggering the SIGSEGV. The call is leading to the JNI API so I included the "hotspot/src/share/vm/prims" directory to the source dirs in the debug section. However, I could not see any effect. Does anybody have an idea how I can step into the C++ method calling the Java main method?
When the SIGSEGV causes the Netbeans debug view to stop, the call stack shows the expected call stack. However, instead of the C++ code it just shows assembler code while displaying the names of the C++ classes. The initial caller is "?? ()". Is there some way to see the C++ code or do I have to manually map the assembler code to the C++ code? I read a great article by Volker Simonis where he describes that such unknown frames relate to generated code. However, I'm still puzzled that the consecutive caller frames show class and method names. Is it a problem with source lookup or simply relates to the first unknown frame?
Did you compile hotspot in debug mode, i. e. make all_debug? If hotspot is optimised than code may be run in different order than it's in source file, and some symbols can be stripped out, preventing debugger to give you meaningful info, or setting a breakpoint.

Issue with compiling a program into an EXE, VB 6

I have recently edited a fellow student's data collection software to my specifications. The program works fine when I run within Visual Basic 6, however ideally I would like to compile the program into an .exe file so I can run it from any PC. However, when I select the option to turn it into an exe, I get the following error while its compiling:
Compile Error: Sub or Function not defined.
I was curious why my program will run from within Visual Basic, but can't compile into an exe. Any fixes/suggestions would be greatly appreciated!
You must just be running the app in the IDE by using Start (F5) - this does not do a full compile so won't catch all compile errors. I suggest you always use Start With Full Compile (Ctrl+F5) - then it will show you where the errors are.
You can create a custom control bar button to do the Start With Full Compile - saves typing CTRL+F5 all the time.
at the begining of every file, write "option explicit". This changes vb behavior from weak typed to strong typed.
What this means is that when you put a string into an integer, then the vb will tell you right away, or at least when you press "run". In a weak typed mode, the program will run until it encounters a fault, like "Sub or Function not defined" then crash.
When you compile into an "exe", vb needs to do extra sanity checks much like "option explicit" would do. This is why you don't see the problem while normal execution. It is still there, lurking, but you probably don't execute the problematic line.
It is very important that you use this keyword in every vb source file you have, otherwise you'll see problems like this all the time.
It allows you to run the program even though it won't compile due to the Compile On Demand feature the IDE supports. As noted in other posts you can CTRL-F5 to do a full compile, or you can go into Options --> General and turn off Compile On Demand...(saves a lot of CTRL-F5s)

Resources