BeaEngine64

[FlySky]

Good evening guys,

Wondering the following.
I am playing around with BeaEngine x64.
It comes in two forms, .dll and .lib.

Using the .dll
calling LoadLibrary, GetProcAddress to retrieve pointer to the Disasm exported function all is going well.

Is it possible to use the .lib instead?
It's compiled using MinGW and it's been discussed that GoASM has problems reading the .lib file.
Is there any way to generate a valid .lib file to use with GoASM? Or does someone have an .lib that works on GoASM?
The ones that ship with the zip from BeaEngine site are crashing for me.

[dedndave]

i think it was in the old forum, someone had made an INC file for the 32-bit version
probably wouldn't take much effort to create a 64-bit INC file, using that one as a guideline
in fact, Beatrix signed in and had some input (might help limit your search)

[Donkey]

I used the BeaEngine for a project once, I'm pretty sure I wrote a header file for it. I'll try to find it in the morning.

[wjr]

Yes, I did a quick test and managed to use the lib instead. On the 64-bit side, did you use INVOKE?

Code Select Expand


INVOKE BeaEngine64.lib:Disasm, ADDR MyDisasm


[FlySky]

Hey Guys,

It doesn't seem to work here for me.

I am getting the GoASM files from: http://www.beaengine.org/downloads

Than declaring the following in my project:

#include BeaEngineGoAsm64.inc
Disasm = BeaEngine64.lib:Disasm

Structure and other definitions in DATA section:
MyDisasm              _Disasm <>
szoutofblock          DB 'Security alert. Disasm tries to read unreadable memory', 0
i                     DD 100

invoke BeaEngine64.lib:Disasm, offset MyDisasm //crashes
invoke Disasm, offset MyDisasm //crashes

Using LoadLibrary to load BeaEngine64.dll from the same package and than using GetProcAddress to retrieve pointer to Disasm function all is working perfectly fine.

The following crash occurs when linking the .lib and invoking it:

(b04.1350): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
00000000`40007739 ??              ???

Function is being called from:
00000001`4003ce55 488b442430      mov     rax,qword ptr [rsp+30h]
00000001`4003ce5a 4889c1          mov     rcx,rax
00000001`4003ce5d 488b80f0010000  mov     rax,qword ptr [rax+1F0h]
00000001`4003ce64 480fb600        movzx   rax,byte ptr [rax]
00000001`4003ce68 488d1549510000  lea     rdx,[image00000001_40000000!opcode_map1 (00000001`40041fb8)]
00000001`4003ce6f ff14c2          call    qword ptr [rdx+rax*8] //call that crashes

so that is why I believe there is something with the .lib

[FlySky]

I found the problem.
Sorry for double posting but to keep the topic clear.
It has to do with the golink switch: /LARGEADDRESSAWARE

So what I figured out:
1. Using the  /LARGEADDRESSAWARE switch and the .lib will cause acces violation error.
2. Using the  /LARGEADDRESSAWARE switch and using LoadLibrary with BeaEngine.dll and GetProcAddress to retrieve Disasm export all is going fine.
3. Removing the switch and using the .lib all is working just fine.
4. Removing the switch and using LoadLibrary with BeaEngine.dll and GetProcAddress to retrieve Disasm export all is going fine.

Is there any way to fix option 1?.

[wjr]

Thanks, I was able to reproduce the problem case with /LARGEADDRESSAWARE. The call is to an address in a function table. Unfortunately the high DWORD gets zeroed out for the function address, causing the exception. The relocation type 1 appears correct in the lib file. This somehow switches to type 2 in the obj file. Looking into it...

[wjr]

The LIB file is fine. I suspect that there was an earlier version of the LIB file, but that it was not /LARGEADDRESSAWARE, so it wouldn't be useful if that is what you are looking for. The line that crashes was probably call [opcode_map1+rax*8] and this would have needed adjustment to the current form to handle large addresses. Interesting, there were already adjustments to GoAsm in v0.56.03d which fixed some relocation record handling in static libraries (that LIB file in particular helped identify the problem).

So far I have made further GoAsm changes to handle type 1 relocations properly (as well as type 3 also in this file), resulting in proper linking, removing the access violation error. However, all is not just fine with options 1 AND 3. The LIB file has .pdata and .xdata that GoAsm puts into the OBJ file const section, so these do not get properly recognized and handled at the linking stage. Looking into it... also trying to finish up with SSE4, so probably get this fix in with v0.61.

Best to use option 2 or 4 for now.

[FlySky]

Wjr,

I will go with option 2 for now. Thanks for looking into it.
We'll wait patiently for the fix.

Good news about adding SSE4. Keep it up! you're doing a great job.

[Donkey]

Hi, I checked my older code base and found that I had started using BeaEngine but had eventually dropped it in favor of the IDebugControl interface. It wasn't so much for problems (as far as I can remember) but because the program I needed a disassembly engine for was already using the IDebugXXX interfaces and it made little sense to load yet another library when Windows provides a fair disassembler anyway. At any rate if you would like to look at the IDebugXXX code I wrote it is available in the RadAsm section of the board somewhere, Debug32 and Debug64, both can output assembly code lines from a program.