On 10/15/2024 8:37 PM, Mike Terry wrote:
> On 15/10/2024 20:40, Chris M. Thomasson wrote:
>> On 10/15/2024 9:06 AM, Mike Terry wrote:
>> [...]
>>>> _______________________
>>>
>>> You seem to be compiling the wrong program. The source code is
>>> halt7.c and has nothing to do with ct_threads.
>>
>> Shit happens Mike, sorry about that. Anyway, it compiles with C for x86:
>>
>> https://i.ibb.co/1bKYQMv/image.png
>>
>> but crashes during a run:
>>
>> https://i.ibb.co/T0f1Wjg/image.png
>>
>> The call stack for the error is:
>>
>> > ct_thread_playground.exe!Init_Halts_HH(unsigned int * * Aborted,
>> unsigned int * * execution_trace, Decoded * * decoded, unsigned int *
>> code_end, unsigned int P, x86_Registers * * master_state,
>> x86_Registers * * slave_state, unsigned int * * slave_stack) Line
>> 544 C
>> ct_thread_playground.exe!H(void(*)() P, void(*)() I) Line 701 C
>> ct_thread_playground.exe!D(int(*)() M) Line 1369 C
>> ct_thread_playground.exe!main(...) Line 1376 C
>> ct_thread_playground.exe!invoke_main() Line 78 C++
>> ct_thread_playground.exe!__scrt_common_main_seh() Line 288 C++
>> ct_thread_playground.exe!__scrt_common_main() Line 331 C++
>> ct_thread_playground.exe!mainCRTStartup(void * __formal) Line
>> 17 C++
>> kernel32.dll!74d17ba9() Unknown
>> [Frames below may be incorrect and/or missing, no symbols loaded
>> for kernel32.dll]
>> ntdll.dll!76fdc0cb() Unknown
>> ntdll.dll!76fdc04f() Unknown
>>
>
> It looks like you've compiled halt7.c and linked it to form an
> executable, then you're running that executable as an OS process?
> That's not what you need to do.
>
> halt7.c needs to be compiled to halt7.obj (assuming Windows) which is a
> COFF file. You've done that bit. The halt7.obj file is passed as a
> parameter to PO's x86utm.exe, whichx reads the COFF file as input data,
> and provides a virtual x86 environment in which to "run" the obj code.
> I'm actually a bit surprised that you were able to link halt7.obj to
> create an executable!
>
> So if you want to try out the code in halt7.c, you will need to build
> x86utm.exe, which provides the virtual environment in which it "runs".
> The source on Github has all the source, including the PO-written code
> and the code coming from libx86emu, which is the x86 emulation software
> PO uses. There is a MSVS project file to do the build, or you could
> compile/link the files manually if you had to. There are 6 C
> compilation units (from libx86emu) and 1 C++ compilation unit
> (x86utm.xpp). I think the code is written as 32-bit. (Obviously you
> need the header files also on Github.)
>
> So the process you will run in your debugger is x86utm.exe. That makes
> it tricky to "step through" halt7.c code, since halt7.c code is just
> data being manipulated within the x86utm process.
>
> The reason you can't just link halt7.c to an OS executable and run it is
> that it is full of calls to "primitive" ops like Allocate() and
> DebugStep() which are intercepted by x86utm.exe and processed within
> x86utm. Like a supervisor call mechanism.
>
>
> Mike.
>
The one other person in the world that best understands my code.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
|
|