Details
-
New Feature
-
Resolution: Fixed
-
Major
-
None
Description
Ping learn_more We have two bugs in one, but let's see if it's easy to attack:
Our /reactos/sdk/tools/gen_baseaddress.py generates in x64 GCC clean builds (under Linux the tested) wrongly a /reactos/sdk/cmake/baseaddress_msvc_x64.cmake because current conditional elif:
https://github.com/reactos/reactos/blob/5c2ec83fa7658fb472313e094f7a29a216fe16b1/sdk/tools/gen_baseaddress.py#L353
is true for MSVC_x64, but also to gcc_x64 and Clang_x64.
Moreover we don't have a own baseaddress to the GCC_x64 in this condition:
https://github.com/reactos/reactos/blob/5c2ec83fa7658fb472313e094f7a29a216fe16b1/CMakeLists.txt#L348
So maybe a fix like the HBelusca said:
else() |
if (ARCH STREQUAL "amd64") |
include(sdk/cmake/baseaddress_gcc_x64.cmake)
|
else() |
include(sdk/cmake/baseaddress.cmake)
|
endif()
|
endif()
|
could be a good option.
PS: hbelusca commented in the chat that maybe the .rossym is not the best way to use this, since some builds might not have kdbg. We still need to fix those collisions if we want to use GCC x64 or Clang x64.
Attachments
Issue Links
- relates to
-
CORE-14831 CORE-11382 addendum: fix 3+1 remaining "XYZ has no base address", The python script for regenerating the GCC base addresses does not properly cover fusion, fusion1_1, fusion2_0, localspl_apitest.dll
- Resolved