How will it be different? The assembly code that the debugger shows you, is the assembly being generated by the compiler. Yes, you can get different assembly based on your compilation optimization flags - but the debugger will show you that code too. Debuggers don’t alter the code - they show you as honest a view of what is being executed on your CPU as is possible.
As for decompiling and inspecting your code with Ghidra, what you will need to do is learn how the compiler optimization semantics effects the code that you’ll see in front of you, first of all. There are optimization flags where processBlock() will be optimized away (maybe) and there are flags where you will have huge binaries and all your functions will be where you expect them to be, too.
If you are just starting out with reverse engineering, don’t bother with Ghidra. Instead, learn what the -S (emit assembly) flag does with your compiler, and read the generated assembly code - FIRST. Then, change your optimization flags, do another full rebuild, and re-read the assembly code again. You will gain much more knowledge this way, starting out, than by diving into Ghidra head-first without understanding these things.
Use your compiler. Know your compiler, always. It is the front line for all of your engineering and reverse-engineering efforts.
Some interesting details about the -S flag and how to use it here:
Another tool that I highly recommend if you want to get started to learn how C++ code translates to assembly using different compilers and compiler optimisation flags is the compiler explorer: godbolt.org. This video might be helpful as well getting started as it shows both the usage of compiler explorer and some good basic overview of how to read assembly code Just Enough Assembly for Compiler Explorer
I see. But once the code is emitted as optimized flags, is there a way to catch the starting point (i.e. processBlock()) by putting a … comment for example? Else, how can i start to catch the process function?
One way to find where processBlock starts is to search for the assembly instruction that changes the mxcsr register, which is used by ScopedNoDenormals (assuming you’re using that at the very start of processBlock and that you’re on Intel). Instructions to search for are ldmxcsr and stmxcsr.
No, comments are not part of your generated code. The way to do it is with your normal debugger (non-Ghidra) - merely put a breakpoint on processBlock(), run until you hit the breakpoint, then use your IDE to show you the assembly of the code at the current breakpoint. This will give you enough info to actually ‘reverse engineer’ what your code is doing in assembly but it will also show you the address of the processBlock method in memory - and later on when you are ready, you can then use that memory address in Ghidra to jump straight to that block of disassembled code …
Projucer doesn’t have anything to do with debugging - its a front-end for generating JUCE-based projects that can be easily ported to different platforms - the .jucer file is all you need to generate the projects on each OS you wish to support with your final product.
VSCode includes the ability to debug - and if you are not familiar with it yet you should start there. You can do a lot of reverse engineering with VSCode and its debugger, alone - and until you’ve done this you really won’t have the insight you need to continue further with more advanced reverse-engineering tools such as Ghidra.
Really, it seems like you need to bootstrap your own local debugging capabilities, and this is definitely worthwhile to do with VSCode.
Without install the whole debugger things, can you kindly write to me to which instructions I could search on Ghidra? Such as the ones suggested by @kerfuffle about ScopedNoDenormals (which I didn’t use).
Not sure which Clamp function you use, but as suggested above, try out compiler explorer. Here you can see e.g. the assembly generated for std::clamp. Note that this might still greatly vary depending on the compiler (version) used an the context where the function is called, the compiler might decide to compute it differently in case the surrounding code looks different since it could re-use computations done somewhere else and a lot more.
This is a custom clamp function. Free functions from the JUCE library all start with a lowercase letter by convention and furthermore the equivalent function from JUCE is named jlimit. Last but not least what you are showing there is not a function but a function template with a super simple implementation – this will most likely be completely inlined by the compiler anyway.
If things like that aren’t clear to you, you will probably have no success finding out anything meaningful with a tool like Ghidra.
So what are you trying to achieve here in general? In case you will finally find the processing code, what do you want to do with it? Are you planing to re-use the decompiled code and re-use it in a new project or what is your plan?