C++: C++ to machine code via TDM-GCC

[nnnik]

You should look for a beginners C++ tutorial before attempting this.

[jeeswg]

Well I guess I never mentioned that you need to use VarSetCapacity to initialize data in them then.

Did you fix this yet? Can you explain what you meant. Thanks.

[nnnik]

You need to use VarSetCapacity and NumPut to modify the binary data of the MCode.

[Helgef]

What happens is that gcc optimises out the loop entirely for your stringedit function, instead it wants to read the first 16 bytes of the sequence 00,01,... in one instruction, because that is faster (yes, gcc figures out that the code can only have one outcome). How can we know? We can look at the assembly code, -S flag. What to do? Basically, you need to tell the machine code where to find these first 16 bytes, as hinted by nnnik, so numput/varsetcap it is. In general, this is not fun because every time you change your code, there is extra work, and 32 and 64 bit versions also differs. The simple solution is to avoid the optimisation, eg, try -O2 instead of -O3. You might eventually have found out that it would work with another flag, but you would not suddenly realise what is happening and you will not find it on google either, you will have endless debugging-from-hell issues (and certainly not only regarding optimisations) if you proceed without taking the advice to learn c/c++ first. You will have plenty such issues anyways ofc.

The exception probably comes from trying to dereference a null pointer, because you didn't provide a pointer (offset on 64 bit) to the data.

cheers

[jeeswg]

- GREAT. I used the -O2 flag instead of the -O3 flag, and my function worked.
- I mentioned in the OP if anyone could suggest any good links for the TDM-GCC command-line parameters.

- So changing the command-line flag (TDM-GCC), and the fact that AStr modifies the string (AutoHotkey) have been the two problems I've experienced so far.
- I'm yet to have any problems with C/C++, but I'd highly recommend to the other posters (Helgef and nnnik) to learn more about C/C++.
- @Helgef: you recommended in the 'InBuf function currently 32-bit only' thread that focusing on C++ to machine code, might be a better use of time than focusing on ASM to machine code, generally speaking I agree. However, it looks like we need to know a bit about ASM, for use with C++, after all, with regard to O2/O3 at least.

- I heard NumPut/VarSetCapacity mentioned, isn't it equally correct to say that we should edit the hex string for the machine code.

- I found some threads that seemed relevant, but the explanations and examples were lacking, and thus not much use. I need info to help predict and resolve problems generally, and not the minimum information required to fix one machine code function.
MCode access violation on: long long >> arg - Ask for Help - AutoHotkey Community
https://autohotkey.com/board/topic/7125 ... -long-arg/
DllCall Error with MCode Function - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?t=683
DllCall: "UChar*", buffer vs. "UInt", & - Ask for Help - AutoHotkey Community
https://autohotkey.com/board/topic/5398 ... r-vs-uint/
basic MCode c++ array question - Ask for Help - AutoHotkey Community
https://autohotkey.com/board/topic/9065 ... -question/
MCode function + onlinegenerator (x86 and x64) - Scripts and Functions - AutoHotkey Community
https://autohotkey.com/board/topic/8928 ... 6-and-x64/
- Seeing as I didn't know for definite what the problem was, I had dozens of other candidate threads to go through.

- Many thanks to both of you for your help here, I've got enough knowledge now to do some good codes.

[nnnik]

This is just the beginning of issues.
From my experience MCode works best when running completely dynamic code that does not have references towards other functions.
Your stredit function had a static outcome and you immediately get issues.
All those problems stem from catching the machine code before it gets send to the linker and turned into a dll or exe which gets correctly linked by the windows linker on runtime.
In the case of your broken function it would insert a pointer to the data that your code wants to write in the necessary places.
As soon as C pushes some work on the linker your function won't work and throws a 0xc0000005.
And C pushes work on the linker for more reasons than I can be bothered to learn.
https://msdn.microsoft.com/en-us/library/ms809762.aspx

[Helgef]

- I'm yet to have any problems with C/C++
I've got enough knowledge now to do some good codes.

I expected a different reaction .

isn't it equally correct to say that we should edit the hex string for the machine code.

I wouldn't convert an address to a string only to convert it back to number. In this example, the 32 bit code needs an address, so it cannot be hard coded. The 64 bit needs a relative address so it can be hard coded. You also need to make sure the memory (of the constant 16 byte data in the example) is 16-byte aligned, varsetcapacity doesn't guarantee that. I use arrays for my binary code, often I can only insert stuff in the array when needed. If I used hex strings, I'd use numput on the allocated memory directly.

it looks like we need to know a bit about ASM

As I said in that thread, it is great for learning, but when you want to produce actual usable code, writing it in c / c++ is generally preferred.

This is just the beginning of issues.

Indeed we need pop corn emoticons on this forum.

Good luck, cheers.