- Add context structure and definitions, NEON128 structure,
runtime function entry, dispatcher context, scope table
All definitions are based on the latest SDK for arm64.
[SDK] Use _TARGET_PE64 in the pefixup
[GENINC] Add AA64 identifier for ARM64 PE binaries
CORE-17518
- Add some of the missing CMake adjustments to continue the configure and compile process with ARM64 MSVC
- Created quick stubs for the functions in SDK needed to finish the configuration process
- Put in an ARM64 option for spec2def
CORE-17518 CORE-17615
For some bizarre reason ARM toolchains have some peculiar issues with various va_arg macros,
as this is not the first time one of these is problematic (though I don't remember the previous one,
it was a long, long time ago ™️).. They always seem to expect va_list as an argument though, so
let's make them happy and by extension make ros-tools compile on Linux/ARM(64) compile again!
Not defining the type breaks the compilation on (at least arm) Linux. Add a check for Linux-as-build-host to make it pass.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Also, put include directory next to the library and use
target_include_directories(.. INTERFACE ..) to get this right.
This is because :
- Having includes & implementation in two different places buggers me
- This makes sure that there is no "if it compiles everything is fine" behaviour from anyone
because now even static libraries need it for GCC amd64 build
Also add __USE_PSEH2__ define for the non SEH-aware compilers out there and use it in a few headers
where we define macros involving __try
\#pragma REACTOS SEH(except)
\#pragma REACTOS SEH(finally)
What it does is counting the number of SEH __try blocks and emit the proper assembly statements at function prologue
It also checks for mixing C++ & SEH exception handling, which wouldn't work
ARM32 seems to use the same type defines as i386 and friends.
Let's allow the thing to be compiled again!
CORE-17517
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
x86 version needs input and output file names as arguments, even if is called with
input file name = output file name.
x86 version also accepts a -s argument to the root path of ReactOS sources
Make x64 version take the same arguments.
This patch fixes vertex processing issue of bug 33770.
The problem comes from the fact that even if the call succeeds,
the game interprets a non null error_messages pointer as an error.
By calling D3DCompile we use a newer version of the compiler which is more
strict and generates the following warning.
- warning X3206: 'dot': implicit truncation of vector type
- warning X3206: implicit truncation of vector type
- warning X3206: 'mul': implicit truncation of vector type
D3DCompileShader does not generate such warnings.
These is confirmed in the DX SDK release note:
New Warning X3206: Implicit Truncation of Vector Type
Beginning in the August 2009 release of the DirectX SDK, the compiler will warn
when an implicit truncation of a vector type occurs.
The warnings cannot be disable so this patch filters out these strings in D3DCompileShader
and reset the error messages pointer if the resulting buffer is empty.
Try 2:
- only filter out lines containing "X3206:" in case d3dcompiler_43 has localization
Try 3:
- use move in place instead of copying the buffer
Try 4:
- filter simplification by Sebastian and remove 'mul' testing left-out in search string
wine-staging patch by Christian Costa <titan.costa@gmail.com>
Signed-off-by: Sven Baars <sbaars@codeweavers.com>
Signed-off-by: Matteo Bruni <mbruni@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
wine commit id a097f54ea1e7e75b78842ceb835f5db5f08fea06 by Sven Baars <sbaars@codeweavers.com>
