[amd-staging] cherry- pick missing patches from rocm-systems#37
Merged
lancesix merged 27 commits intoamd-stagingfrom Apr 14, 2026
Merged
Conversation
In 4a7634bbec348a431c3d68b49b7ff523faca0a75 ("third_party/libdxg:
Adjust libdxg headers to compile with mingw"), we adjusted the headers
to make them compilable with mingw32.
When compiling with MSVC or with clang++ targeting
x86_64-pc-windows-msvc, we run into the same problems described in
that commit. As said there, the libdxg headers are meant to be used
on Linux (WSL). So switch the '#ifdef' guards to check for __linux__
instead of trying to come up with the right checks that would detect
MSVC, Clang and GCC/MinGW.
Change-Id: I0c5501005cd688bd9fdaf66e95a738ae66f72622
commit-id:ace8e65a
The following patch removes the windef.h include from amd-dbgapi.h.
That alone surprisingly breaks src/os_driver_kmd.cpp, as we'd start
seeing many instances of:
rocm-dbgapi/src/os_driver_kmd.cpp: In function 'std::string amd::dbgapi::to_string(T) [with T = long int; std::string = std::__cxx11::basic_string<char>]':
rocm-dbgapi/src/os_driver_kmd.cpp:836:8: error: narrowing conversion of '3221225495' from 'DWORD' {aka 'long unsigned int'} to 'long int' [-Wnarrowing]
836 | case STATUS_##x: \
| ^~~~~~~
This is because ntstatus.h and winnt.h define some STATUS constants differently:
$ grep STATUS_NO_MEMORY /usr/x86_64-w64-mingw32/include/* -rn
/usr/x86_64-w64-mingw32/include/ntstatus.h:268:#define STATUS_NO_MEMORY ((NTSTATUS)0xC0000017)
/usr/x86_64-w64-mingw32/include/usbdi.h:28:#define USBD_STATUS_NO_MEMORY ((USBD_STATUS) 0x80000100)
/usr/x86_64-w64-mingw32/include/winnt.h:1425:#define STATUS_NO_MEMORY ((DWORD)0xC0000017)
NTSTATUS is long, DWORD is unsigned long.
winnt.h does not define all the constants we need. Also, NTSTATUS is
the one we use throughout src/os_driver_kmd.cpp.
So fix this by telling windows.h to not define the STATUS constants.
That can be done by defining WIN32_NO_STATUS.
With MSVC or clang targeting x86_64-pc-windows-msvc, we need to
explicitly include winternl.h for the NTSTATUS typedef itself. MinGW
happen to get it automatically via some win32 header including
bcrypt.h.
Ref: https://mschaef.com/windows_h_is_wierd
Change-Id: Ib4f13915cb9de78d4173c47b5ab2aaa4a1ed0447
commit-id:84c49702
[amd-dbgapi] In file included from D:/therock/src/rocm-systems/projects/rocdbgapi/src/logging.cpp:21: [amd-dbgapi] In file included from D:/therock/src/rocm-systems/projects/rocdbgapi/src\logging.h:24: [amd-dbgapi] In file included from D:/therock/build/debug-tools/amd-dbgapi/build/include/amd-dbgapi\amd-dbgapi.h:546: [amd-dbgapi] In file included from C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\shared\windef.h:24: [amd-dbgapi] In file included from C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\shared\minwindef.h:182: [amd-dbgapi] C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\um\winnt.h:169:2: error: "No Target Architecture" [amd-dbgapi] 169 | #error "No Target Architecture" [amd-dbgapi] | ^ [amd-dbgapi] C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\um\winnt.h:253:2: error: Must define a target architecture. [amd-dbgapi] 253 | #error Must define a target architecture. [amd-dbgapi] | ^ We are including windef.h instead of windows.h to minimize global namespace polution. We only need the include for HANDLE and DWORD, which are simple typedefs. So remove the header inclusion and define our own versions of those. Change-Id: I83348e1457d95452d3cad59b329bf9f4e57fc386 commit-id:e41ab5e4
Compiling dbgapi with clang++ targeting x86_64-pc-windows-msvc fails
with the following warning (turned into error):
.../rocdbgapi/src\logging.h:83:9: error: implicit conversion between pointer-to-function and pointer-to-object is a Microsoft extension [-Werror,-Wmicrosoft-cast]
83 | ss << v;
| ^
That's in the to_string template function. An example of a function
pointer getting there comes from amd_dbgapi_disassemble_instruction,
which passes its 'symbolizer' argument to TRACE_BEGIN. 'symbolizer'
is a function pointer.
Note: Converting function pointer to data pointer in ISO C++ is
conditionally-supported, i.e., implementation-defined:
https://eel.is/c++draft/expr.compound#expr.reinterpret.cast-8
It is necessarily valid POSIX, as dlsym returns void *, and also valid
on WIN32 as an extension. In any case, we were already assuming that
works, just implicitly.
Change-Id: Ida71fe78bf3dc9efacf196b7c0363aeacabc4626
commit-id:579926d6
update_code_objects: read full struct r_debug and struct link_map per iteration instead of separate offsetof reads for each field. This reduces the number of iocts needed to process the updated code object list. read_string: align the first partial read to the host memory cache line size and use four cache lines per chunk.
Replace the linear search over code objects when walking the dynamic linker map with an unordered_map keyed by loaded_address. When the link map reports the same address with a different URI, destroy the previous stale code object and insert a new one. Clear the index whenever the code-object set is torn down (detach, runtime_enable failure) and remove entries in the existing mark/sweep pass so the map stays consistent with the handle set.
In a future change, to solve address space compatibility issues between device specific architectures and generic architectures, all address spaces will be made global. This future change will make it impossible to specialize the generic address spaces and hold architecture dependent apertures configurations. In order to determine the dependency of a generic segment address, we will now need to use agent. address_space_t::lower: This is were the conversion from a generic address space to a local or private_* address space using the agent specific apertures will be done. For now, just add the unused agent_t. amd_dbgapi_address_dependency: add process_id and wave_id arguments and validate them. Lower the segment address using the wave's agent, then call address_space_t::address_dependency. Notable change: reading/writing memory with amd_dbgapi_read_memory/ amd_dbgapi_write_memory now returns an INVALID_ARGUMENT_COMPATIBILITY error if the address space is the generic address space and the wave_id is WAVE_NONE. Prior to this change, the memory operation was executed if the generic segment address was a global address. Change-Id: Ia3911e3ec06390859e1720710ab953bfabd8c7a3
Since the apertures configurations are agent dependent, move the apertures configurations from the generic address space to the agent. Use the agent's os_info to set the memory regions. Change-Id: I476d83fa294fbc5b8d7f0ff20eb3f41b71d60fe1
The Windows implementation of get_self_path assumes MAX_PATH is the maximum path length, but that's not really true on modern Windows with long path support enabled. Reimplement the function using GetModuleFileNameW, which unlike GetModuleFileNameA is not capped to MAX_PATH. Refactor the wide string to std::string conversion from kmd_driver_t::get_adapter_name to a shared routine. Change-Id: Icde9428838b1c9553fa1fcaf5508e76485f811b0 commit-id: b4fb790c
Don't pass --version-script to the linker on Windows. GNU ld accepts it, which has the effect to exporting all symbols marked with default visibility (instead of all symbols), but it does not work with MSVC's linker, nor with LLVM's lld-link: [amd-dbgapi] [25/25] Linking CXX shared library rocm-dbgapi.dll [amd-dbgapi] lld-link: warning: ignoring unknown argument '--version-script=D:/therock/build/debug-tools/amd-dbgapi/build/src/exportmap' [amd-dbgapi] lld-link: warning: ignoring unknown argument '--no-undefined' Instead, tweak the AMD_DBGAPI_EXPORT_DECORATOR definition to use __declspec(dllexport) on all Windows toolchains, including MinGW with GNU ld. If GNU ld sees any symbol with __declspec(dllexport), then it switches to only exporting those symbols. If/when we need more control over the exported symbols, we should look into a .def file instead, which works on all Windows toolchains. Change-Id: I01b586c8fa0d64b103174d3082677d200131b17a commit-id:ba507704
I accidentally left tabs in src/os_driver_kmd.cpp last time I touched kmd_driver_t::xfer_agent_memory_partial. This untabifies it. Change-Id: I9887da03f0c44f271935afb8ec2ffbc3cb0a0bca commit-id:bf0644b8
When compiling in release mode, where dbgapi_assert is a no-op, we get:
/home/pedro/rocm/gdb/build-rocm-ci/rocm-dbgapi/src/os_driver_kmd.cpp: In lambda function:
/home/pedro/rocm/gdb/build-rocm-ci/rocm-dbgapi/src/os_driver_kmd.cpp:2198:18: error: unused variable 'new_misalign' [-Werror=unused-variable]
2198 | size_t new_misalign = (read != nullptr
| ^~~~~~~~~~~~
Fix it with [[maybe_unused]].
Change-Id: Ifd300615ff10fb63a6041b3777a3ef7ac1fdf536
commit-id:c2af4fb0
Instead of disabling -Werror for src/os_driver_kmd.cpp, make libdxg/include/ a system includes path, which makes the compiler disable warnings for headers in that path. Change-Id: If8252d486523ce99666dfa12bb181d1126888e4b commit-id:c6b8f796
The comment in watchpoint_t::watchpoint_t does not match the code.
Specifically, it says:
Stable := ~(next_power_of_2 (Start ^ End) - 1)
But the code does:
uint64_t stable_bits
= -utils::next_power_of_two ((first_address ^ last_address) + 1);
Which is the equivalent of:
Stable := ~(next_power_of_2 (Start ^ End + 1) - 1)
^^^^
So the "+ 1" is missing in the comment. The code is correct, the
comment is wrong. The "+ 1" is needed when "Start ^ End" is already a
power-of-two.
To illustrate, in the example given, The missing "+ 1" makes no
difference:
First: ...01000100 /* 0x44 */
Last: ...01001000 /* 0x48 */
d = Start ^ End = 0x44 ^ 0x48 = 0x0C /* 1100b */
Without +1:
next_power_of_2 (0x0C) = 0x10
With +1:
next_power_of_2 (0x0C + 1) = next_power_of_2 (0x0D) = 0x10
However, when 'd' is already a power of two:
next_power_of_two (d) == d
While what we actually want is:
smallest power-of-two strictly greater than d
So we need to compensate by doing:
next_power_of_two (d + 1)
Which effectively turns it into:
smallest power-of-two > d
I think we should tweak the example in the comment to be a case where
it the missing +1 matters, like:
First: ...01000000 /* 0x40 */
Last: ...01001000 /* 0x48 */
d = Start ^ End = 0x40 ^ 0x48 = 0x08 /* 1000b */
Without +1:
next_power_of_2 (0x08) = 0x08
With +1:
next_power_of_2 (0x08 + 1) = next_power_of_2 (0x09) = 0x10
This commit does that too.
Also tweak the code to use "~(X - 1)" style instead of "-X" to match
the comment style, and also because this fixes a warning ("unary minus
operator applied to unsigned type, result still unsigned") when
compiled with MSVC, which is what made me look at this in the first
place.
Change-Id: Ia18907dec7cb69be64aa9b8806d90350b0a549b4
commit-id:cd7c5460
MSVC warns like so: D:\therock\src\rocm-systems\projects\rocdbgapi\src\utils.cpp(233): warning C4996: 'vsprintf': This function or variable may be unsafe. Consider using vsprintf_s instead. To disable deprecation, use _CRT_SECURE Fix it by using vsnprintf instead. While at it, vsnprintf returns an int, and let's add an assert that it didn't fail. Change-Id: I6464ccf3c4ad3c314a216b148f1ecafe5ecd369e commit-id:d18eb08e
I tried to compile dbgapi with MSVC, and by default, MSVC issues a
large number of warnings around conversions, like:
D:\therock\src\rocm-systems\projects\rocdbgapi\src\memory.h(191): warning C4244: 'argument': conversion from 'amd_dbgapi_size_t' to 'int', possible loss of data
D:\therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(129): warning C4244: 'initializing': conversion from 'Integral' to 'const uint32_t', possible loss of data
... and many more.
I think that it's actually good to warn/error on implicit narrowing
conversions, which indeed can lose data unintentially. Particularly
so since our codebase does a lot of bit manipulation.
So I went ahead and fixed all of the warning MSVC threw. More
specifically, all warnings under /wd4244 and /wd4267:
# warning C4244: '=': conversion from '...' to '...', possible loss of data
# warning C4267: '=': conversion from '...' to '...', possible loss of data
I then went back to GCC, added -Wconversion, which warns for the same
things more or less, and fixed the remaining warnings, both on Linux
and mingw.
Then I did the same with Clang, both Linux and Windows.
This patch is the result.
Notes:
Instead of just static_cast, I added a new utils::narrow template function:
template <typename To, typename From> To narrow (From from);
This is a safer version than static_cast -- it checks if we'd lose
data, before doing a static_cast.
The typical style is to use it like so when initializing a new
variable:
auto foo = utils::narrow<uint32_t> (wider_type_value);
When assigning to a pre-existing variable, to avoid having to type the
type of the lhs variable, we have:
template <typename To, typename From> void narrow_assign (To &to, From from);
Used like so:
utils::narrow_assign (dest, src);
utils::narrow depends on std::numeric_limits to do its checking, and
because utils::narrow is passed {agent,global,host}_address_t, we need
to specialize std::numeric_limits for those types.
I added a new utils::split function that makes it convenient to split
a 64-bit value in two 32-bit parts, like so:
auto [lo32, hi32] = utils::split (val64);
Many utils.h template functions hardcode parameters as int type. I
made them template parameters too, which avoids having to cast at the
caller site.
bit_extract is tweaked to allow different source type and return type.
The following operators currently take an int as rhs, as that is a
distance type:
constexpr amdgpu_regnum_t operator+ (amdgpu_regnum_t lhs, int rhs);
constexpr amdgpu_regnum_t operator- (amdgpu_regnum_t lhs, int rhs);
Replace the "int" with a new amdgpu_regdiff_t typedef instead (which
is the signed counterpart of the underlying type of amdgpu_regnum_t
(which is uint32_t), which in practice means it's int32_t, so no real
type change.
However, the "operator-(amdgpu_regnum_t lhs, amdgpu_regnum_t rhs)"
function now returns amdgpu_regdiff_t, a signed integer, instead of
size_t, so that the result can naturally be passed directly as rhs to:
constexpr amdgpu_regnum_t operator+ (amdgpu_regnum_t lhs, amdgpu_regdiff_t rhs);
constexpr amdgpu_regnum_t operator- (amdgpu_regnum_t lhs, amdgpu_regdiff_t rhs);
Some local variables in architecture.cpp have amdgpu_regdiff_t though
at first look you'd think they should be size_t. That's because if
you look closer to the code that actually uses them, you'll notice
that those variables exist only to be used as distances/offsets from
another register.
That's it. Most of the patch is then passing explicit type to
utils::bit_mask, and utils::bit_extract, and using utils::narrow and
utils::narrow_assign.
Change-Id: I08d0f66ae3ad8dfe48ce3af710ad838de8a27a4c
commit-id:d8bac744
Compiling dbgapi with MSVC currently shows a number of warnings like these: D:\therock\src\rocm-systems\projects\rocdbgapi\src\agent.cpp(230): warning C4146: unary minus operator applied to unsigned type, result still unsigned ... D:\therock\src\rocm-systems\projects\rocdbgapi\src\utils.h(313): warning C4146: unary minus operator applied to unsigned type, result still unsigned D:\therock\src\rocm-systems\projects\rocdbgapi\src\utils.h(305): warning C4146: unary minus operator applied to unsigned type, result still unsigned ... D:\therock\src\rocm-systems\projects\rocdbgapi\src\watchpoint.cpp(135): warning C4146: unary minus operator applied to unsigned type, result still unsigned D:\therock\src\rocm-systems\projects\rocdbgapi\src\watchpoint.cpp(136): warning C4146: unary minus operator applied to unsigned type, result still unsigned ... See https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-2-c4146 Since, for unsigned integers: -X == ~(X - 1); Tweak the codebase to use the right hand form, which MSVC does not warn about, and is the more typical way to build a mask anyhow. But instead of doing that change directly in several places, add a utils::alignment_to_mask and utils::mask_alignment_to function that do the bit manipulation in a single place, and that helps giving a clearer meaning to intent at the caller sites. In watchpoint.cpp, the code is a bit mysterious currently, I had to stare at it for a bit to make sense of what it is doing. Rewrite it using mask_to_alignment and align_down, which IMHO make it a lot more obvious. Change-Id: Ic08dd45cdd7db63241b99041f559976d4220fb41 commit-id:ded26fba
Compiling dbgapi with MSVC 2022 results in: [1/25] Building CXX object CMakeFiles\amd-dbgapi.dir\src\debug.cpp.obj D:\therock\src\rocm-systems\projects\rocdbgapi\src\utils.h(139): warning C4067: unexpected tokens following preprocessor directive - expected a newline D:\therock\src\rocm-systems\projects\rocdbgapi\src\utils.h(148): warning C4067: unexpected tokens following preprocessor directive - expected a newline D:\therock\src\rocm-systems\projects\rocdbgapi\src\utils.h(157): warning C4067: unexpected tokens following preprocessor directive - expected a newline ... many more of the same ... This patch fixes it. Change-Id: I659df294e9ba39f3568125948fd7341f520dfd20 commit-id:e2edf0f6
When compiling dbgapi standalone (i.e., outside TheRock) with MSVC, we
get this build error:
D:\therock\src\rocm-systems\projects\rocdbgapi\src\os_driver_kmd.cpp(1310): error C2589: '(': illegal token on right side of '::'
D:\therock\src\rocm-systems\projects\rocdbgapi\src\os_driver_kmd.cpp(1310): error C3878: syntax error: unexpected token '(' following 'expression'
D:\therock\src\rocm-systems\projects\rocdbgapi\src\os_driver_kmd.cpp(1310): error C2760: syntax error: ')' was unexpected here; expected ';'
D:\therock\src\rocm-systems\projects\rocdbgapi\src\os_driver_kmd.cpp(1310): error C3878: syntax error: unexpected token ')' following 'expression-statement'
D:\therock\src\rocm-systems\projects\rocdbgapi\src\os_driver_kmd.cpp(1310): error C2760: syntax error: ':' was unexpected here; expected ';'
D:\therock\src\rocm-systems\projects\rocdbgapi\src\os_driver_kmd.cpp(1310): error C3878: syntax error: unexpected token ':' following 'expression-statement'
D:\therock\src\rocm-systems\projects\rocdbgapi\src\os_driver_kmd.cpp(1384): error C2059: syntax error: ')'
D:\therock\src\rocm-systems\projects\rocdbgapi\src\os_driver_kmd.cpp(1384): error C2589: '(': illegal token on right side of '::'
D:\therock\src\rocm-systems\projects\rocdbgapi\src\os_driver_kmd.cpp(1384): error C2672: 'amd::dbgapi::tracer<AMD_DBGAPI_LOG_LEVEL_VERBOSE>::leave': no matching overloaded function found
The problem is that windows.h defines min/max macros, which conflict
with os_driver_kmd.cpp's use of std::min.
Fix this by defining NOMINMAX before including windows.h.
We hadn't seen the need for this before, because:
- MinGW always defines NOMINMAX.
- When compiling under TheRock with clang/msvc, TheRock defines
-DNOMINMAX on the command line.
Change-Id: If0b2bc4a77b3894628ed309501fe813235a372be
commit-id:e7311ca6
Fixes: [23/25] Building CXX object CMakeFiles\amd-dbgapi.dir\src\os_driver_kmd.cpp.obj D:\therock\src\rocm-systems\projects\rocdbgapi\src\os_driver_kmd.cpp(1370): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) Change-Id: I36c1cce9fe749bafc20cc23b6b14f5c062080c91 commit-id:ebb92f8e
MSVC currently shows this build error: D:\therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(7940): error C7510: 'value_type': use of dependent type name must be prefixed with 'typename' ... followed by cascading build errors... Fix it by adding "typename". Change-Id: Idb1743c43e70c63416a76acc9590765113ffa0eb commit-id:f0dce83e
MSVC gives the following warnings: D: \therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(4116): error C2360: initialization of 'trapsts_read_only_bits' is skipped by 'case' label D: \therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(4111): note: see declaration of 'trapsts_read_only_bits' D: \therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(4120): error C2360: initialization of 'mode_read_only_bits' is skipped by 'case' label D: \therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(4117): note: see declaration of 'mode_read_only_bits' D: \therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(4120): error C2360: initialization of 'trapsts_read_only_bits' is skipped by 'case' label D: \therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(4111): note: see declaration of 'trapsts_read_only_bits' D: \therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(4130): error C2361: initialization of 'status_read_only_bits' is skipped by 'default' label D: \therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(4121): note: see declaration of 'status_read_only_bits' D: \therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(4130): error C2361: initialization of 'mode_read_only_bits' is skipped by 'default' label D: \therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(4117): note: see declaration of 'mode_read_only_bits' D: \therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(4130): error C2361: initialization of 'trapsts_read_only_bits' is skipped by 'default' label D: \therock\src\rocm-systems\projects\rocdbgapi\src\architecture.cpp(4111): note: see declaration of 'trapsts_read_only_bits' Fix that by adding a scope for the case labels that declare variables. Change-Id: I744eb9d140839ab277a4a24ec70d9ed991d86d56 commit-id:fd6cab5c
MSVC currently shows this build error:
D:\therock\src\rocm-systems\projects\rocdbgapi\src\memory.h(146): error C2059: syntax error: '{'
D:\therock\src\rocm-systems\projects\rocdbgapi\src\memory.h(146): error C2334: unexpected token(s) preceding '{'; skipping apparent function body
D:\therock\src\rocm-systems\projects\rocdbgapi\src\memory.h(146): error C2059: syntax error: '.'
D:\therock\src\rocm-systems\projects\rocdbgapi\src\memory.h(149): error C2143: syntax error: missing ';' before '}'
D:\therock\src\rocm-systems\projects\rocdbgapi\src\memory.h(149): error C2238: unexpected token(s) preceding ';'
...
The problem is MSVC and __cplusplus. By default, MSVC has a bit of a
historical quirk: it reports 199711L (C++98) for the __cplusplus
macro, regardless of the actual language version you are using (like
C++17 or C++20).
As far I understood, Microsoft did this to avoid breaking legacy code
that relied on the old behavior, but it creates a headache for modern
cross-platform development.
To solve this, we have two options:
1) _MSVC_LANG
This is a Microsoft-specific macro that correctly reports the C++
standard version currently being targeted by the compiler.
2) /Zc:__cplusplus
MSVC can be told to report the correct value for __cplusplus if you
pass the compiler flag /Zc:__cplusplus.
Approach #2 does not work for us here, since we need this in
amd-dbgapi.h.in, and we can't always guarantee that every user of
dbgapi will have that flag enabled in their build system.
So this patch fixes it using approach #1.
Change-Id: Icb7ca9176fe8b4d8c6e19903c7c05ca724e26945
commit-id:22325de2
MSVC does not have __builtin_trap, resulting in: D:\therock\src\rocm-systems\projects\rocdbgapi\src\queue.h(187): error C3861: '__builtin_trap': identifier not found ... and many more of the same. Reimplement dbgapi_assert_not_reached using __debugbreak + abort. Add the abort to match better the semantics of __builtin_trap, which is noreturn. I.e., to avoid someone catching the __debugbreak in a debugger and then continuing after the trap. Change-Id: Ic3e0fa5dfd686150a7b9f61564371e521e28d095 commit-id:26be3cb4
Building dbgapi with MSVC currently shows this warning: [19/25] Building CXX object CMakeFiles\amd-dbgapi.dir\src\memory.cpp.obj D:\therock\src\rocm-systems\projects\rocdbgapi\src\memory.cpp(706): warning C4101: 'e': unreferenced local variable ... Fix it by simply removing 'e'. Change-Id: I0de043824b61ed1674b29d314267a030261f0bca commit-id:2b73d660
With all the previous patches in place, all that is left to build with MSVC, is tweaking CMakeLists.txt. That's what this commit does. "/GR-" is the equivalent of GCC's -fno-rtti. "/permissive-" is needed to tell MSVC to enable conforming mode. Otherwise, we get the following errors: D:\therock\src\rocm-systems\projects\rocdbgapi\src\process.cpp(1379): error C2668: 'amd::dbgapi::process_t::range': ambiguous call to overloaded function D:\therock\src\rocm-systems\projects\rocdbgapi\src\process.h(384): note: could be 'amd::dbgapi::handle_object_set_t<amd::dbgapi::agent_t>::const_range_t amd::dbgapi::process_t::range<amd::dbgapi::agent_t>(void) const' D:\therock\src\rocm-systems\projects\rocdbgapi\src\process.h(379): note: or 'amd::dbgapi::handle_object_set_t<amd::dbgapi::agent_t>::range_t amd::dbgapi::process_t::range<amd::dbgapi::agent_t>(void)' D:\therock\src\rocm-systems\projects\rocdbgapi\src\process.cpp(1379): note: while trying to match the argument list '()' D:\therock\src\rocm-systems\projects\rocdbgapi\src\process.cpp(1708): error C2668: 'amd::dbgapi::process_t::range': ambiguous call to overloaded function D:\therock\src\rocm-systems\projects\rocdbgapi\src\process.h(384): note: could be 'amd::dbgapi::handle_object_set_t<amd::dbgapi::agent_t>::const_range_t amd::dbgapi::process_t::range<amd::dbgapi::agent_t>(void) const' D:\therock\src\rocm-systems\projects\rocdbgapi\src\process.h(379): note: or 'amd::dbgapi::handle_object_set_t<amd::dbgapi::agent_t>::range_t amd::dbgapi::process_t::range<amd::dbgapi::agent_t>(void)' D:\therock\src\rocm-systems\projects\rocdbgapi\src\process.cpp(1708): note: while trying to match the argument list '()' Change-Id: I8b1314824a7708ef985d4ab43c0b643a7663133d commit-id:32a6918e
Add a new per-process query to find bits used across all the address-spaces. This is intended to be used by the client to know which bits of an address can be used to carry extra information. Bug: AIROCGDB-26 Change-Id: I523ffef506fd8d2fe1400075e9501ad5f16a54aa
amd-shahab
approved these changes
Apr 14, 2026
Contributor
amd-shahab
left a comment
amd-shahab
left a comment
There was a problem hiding this comment.
Reviewed these cherry picks and they're OK.
Add process_id and wave_id arguments to amd_dbgapi_address_dependency
Move the apertures configurations to the agent
Add AMD_DBGAPI_PROCESS_INFO_SIGNIFICANT_ADDRESS_BITS
Thank you!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
The tooling seems to be missing many recent changes from rocm-system. Manually cherry-pick what is missing.