Add custom kernel name demangler #9134

donwalkarsoham · 2025-08-07T01:02:06Z

Problem solved by the commit

XRT was separate demangler APIs for Linux (GCC API) and Windows (UnDecorateSymbolName) while AIEBU has mangling implementation similar to the one on Linux.

Bug / issue (if any) fixed, which PR introduced the bug, how it was discovered

N/A

How problem was solved, alternative solutions (if any) and why they were rejected

Add custom demangler in XRT common for both Linux and Windows platforms which matches the mangler in AIEBU.
Currently, it supports only argument types char, void and int like AIEBU.
The demangler is similar to the Itanium ABI style: _Z<length><name><types>

length : number of characters in the name string.

name : kernel name in string

types : kernel argument data type as below.

'c' represents the arg is a char.

'v' represents the arg is a void.

'i' represents the arg is an int.

'P' represents the arg is a pointer. Hence, "Pc" = char*, "Pv" = void*, "Pi" = int*

Will be adding support for uint32_t and uint64_t later.

Risks (if any) associated the changes in the commit

Break existing demangling on Linux

What has been tested and how, request additional testing if necessary

1> Successfully ran End to end test on aie4 on Windows and Linux as given below. (It also prints the mangled and demangled name)

1. Test on aie4 Windows with 3 args-

starting vadd thread number: 0
====== 0: vadd started =====
15820: Closing adapter 00000000400000405983770: -> mcdm::device::device(0x40000000)
6805810: hw_type is 5, is_iommu_disabled = 0
6840330: <- mcdm::device::device() this(0x23006370860) handle(0x40000080) adapter(0x40000000)
...
Mangled name: _Z3DPUPcPcPc
Demangled kname: DPU(char*, char*, char*)
...
19298676990: <- mcdm::device::device()
====== 0: vadd passed =====

2. Test onaie4 Linux with 3 args

root@qemuvm:~# ./advanaik/bins/bin/xrt_test 0
====== 0: npu3 xrt vadd started =====
837: PID(982): Created pcidev (0000:02:00.4)
...
mangled kname :_Z3DPUPcPcPc
demangled kname :DPU(char*, char*, char*)
...
19087159717: PID(982): Closed 3
====== 0: npu3 xrt vadd PASSED =====

3. Test onaie4 Linux with no arg

====== 1: npu3 xrt move memtiles started =====
688: PID(989): Created pcidev (0000:02:00.4)
...
mangled kname :_Z3DPU
demangled kname :DPU()
...
7751058106: PID(989): Closed 3
====== 1: npu3 xrt move memtiles PASSED =====

4. Test on aie2p Windows

[INFO] Host test code is created device object
[INFO] ===== Thread 0 Start =====
Host test will create kernel: DPU:dpu
Host code is creating hw_context...
----------- mangled name: _Z3DPUPcPcPcPcPc
----------- Demangled name: DPU(char*, char*, char*, char*, char*)
...
Thread 0, Iteration 0 Finished
===== Thread 0 Finished =====

5. Test on aie2p Linux

_Z3DPUPcPcPcPcPc
DPU(char*, char*, char*, char*, char*)

Documentation impact (if any)

N/A

Signed-off-by: Soham Donwalkar <[email protected]>

gbuildx · 2025-08-07T01:02:25Z

donwalkarsoham - is not a collaborator
Can XRT admins please validate PR

gbuildx · 2025-08-07T01:04:03Z

Can one of the admins verify this patch?

Signed-off-by: Soham Donwalkar <[email protected]>

gbuildx · 2025-08-07T07:25:35Z

donwalkarsoham - is not a collaborator
Can XRT admins please validate PR

larry9523 · 2025-08-07T17:19:39Z

src/runtime_src/core/common/api/xrt_module.cpp

+{
+  //Check if mangled prefix "_Z" is present and length is greater than mangled_prefix_length
+  if (mangled.size() <= mangled_prefix_length || mangled.substr(0, mangled_prefix_length) != "_Z")
+    return "Not a mangled name";


We should throw instead of returning

larry9523

Please throw instead of return on error

larry9523 · 2025-08-07T17:19:58Z

src/runtime_src/core/common/api/xrt_module.cpp

-  std::unique_ptr<char, decltype(&std::free)> demangled_name
-    (abi::__cxa_demangle(mangled_name.c_str(), nullptr, nullptr, &status), std::free);
+  if (idx >= s.size())
+    return "?";


Is this an error condition? If so, we should throw

Yes, added throw.

stsoe

It is possible to use GCC style mangling and write our own Windows mangler / demangler that follows the GCC style? I am asking because it would be useful to have elf files be compatible with available tools, e.g. c++filt?

github-actions

clang-tidy made some suggestions

github-actions · 2025-08-07T17:57:06Z

src/runtime_src/core/common/api/xrt_module.cpp

+
+
+// map of mangled argument types to their demangled string representations
+static const std::map<char, std::string> demangle_type_map = {


warning: initialization of 'demangle_type_map' with static storage duration may throw an exception that cannot be caught [cert-err58-cpp]

static const std::map<char, std::string> demangle_type_map = { ^

Additional context

/usr/include/c++/13/bits/stl_map.h:239: possibly throwing constructor declared here

map(initializer_list<value_type> __l, ^

This clang-tidy warning is valid. Let's move this static std::map inside a function that implements the lookup.

std::string get_demangle_type(char c) { static std::map<...> ...; auto it = demangle_type_map.find(c); return (it != demangle_type_map.end()) ? it->second : "unknown"; }

donwalkarsoham · 2025-08-07T19:18:35Z

It is possible to use GCC style mangling and write our own Windows mangler / demangler that follows the GCC style? I am asking because it would be useful to have elf files be compatible with available tools, e.g. c++filt?

Yes, AIEBU and with this PR XRT will be using Itanium ABI style mangling which is a GCC style mangling independent of the platform (Windows and Linux). I checked online, c++filt supports demangling for Itanium ABI style mangling on Windows and Linux. If the windows system has a GCC or Clang installation on Windows (e.g., through MinGW-w64 or Cygwin) then it will have c++filt.
Thus ELFs generated using Itanium ABI style can be demangled using c++filt on Windows and Linux.

I checked on Linux using c++filt and and it was able to demangle correctly. This below mangling style is used by AIEBU and present in ELF. Note - AIEBU needs some change wrt to scalar types like int, char, uint32_t, etc. which I will be making after this PR gets merged.

% c++filt _Z3DPUPvPcPi
DPU(void*, char*, int*)

stsoe · 2025-08-07T19:44:22Z

It is possible to use GCC style mangling and write our own Windows mangler / demangler that follows the GCC style? I am asking because it would be useful to have elf files be compatible with available tools, e.g. c++filt?

Okay, that comment made no sense. We are only implementing demangle, mangling is in aiebu and is GCC style.

stsoe · 2025-08-07T19:48:44Z

src/runtime_src/core/common/api/xrt_module.cpp

+
+
+// map of mangled argument types to their demangled string representations
+static const std::map<char, std::string> demangle_type_map = {


This clang-tidy warning is valid. Let's move this static std::map inside a function that implements the lookup.

std::string get_demangle_type(char c) { static std::map<...> ...; auto it = demangle_type_map.find(c); return (it != demangle_type_map.end()) ? it->second : "unknown"; }

stsoe · 2025-08-07T19:52:32Z

src/runtime_src/core/common/api/xrt_module.cpp

 static std::string
-demangle(const std::string& mangled_name)
+demangle_arg_type(const std::string& s, size_t& idx)


We don't need this function. Leverage get_demangle_type and pass the char to get the type for. Leave string (s) and index (idx) with caller.

As per our discussion offline, made the changes.

stsoe · 2025-08-07T19:52:50Z

src/runtime_src/core/common/api/xrt_module.cpp

+  // Append "*" for pointer types
+  if (c == 'P')
+    return demangle_arg_type(s, idx) + "*";
+
+  auto it = demangle_type_map.find(c);
+  return (it != demangle_type_map.end()) ? it->second : "unknown";


Fold into get_demangle_type

As per our discussion offline, made the changes.

larry9523 · 2025-08-07T19:53:27Z

src/runtime_src/core/common/api/xrt_module.cpp

+    return demangle_arg_type(s, idx) + "*";
+
+  auto it = demangle_type_map.find(c);
+  return (it != demangle_type_map.end()) ? it->second : "unknown";


how does the caller deal with "unknown"

Currently, the function args will have unknown in it. I can throw and error even if one of the args are not mangled correctly.

donwalkarsoham · 2025-08-07T20:21:11Z

It is possible to use GCC style mangling and write our own Windows mangler / demangler that follows the GCC style? I am asking because it would be useful to have elf files be compatible with available tools, e.g. c++filt?

Okay, that comment made no sense. We are only implementing demangle, mangling is in aiebu and is GCC style.

Sorry if my response was confusing. Let me rephrase it.
AIEBU has its own implementation for mangling which follows GCC style (Itanium ABI) for pointer type arguments - https://github.com/Xilinx/aiebu/blob/49807d3f811933cacdab83094a6b1e08dc509ed7/src/cpp/preprocessor/preprocessor_input.h#L45

In this PR we are implementing demangling in XRT matching the same style which is again following GCC style(Itanium Style).
If your question was, if c++filt supports this type of mangling, then on online research it says that c++filt does supports this type of mangling.
c++filt can be used on Linux and Windows both. I tested on Linux and c++filt demangled the string as expected.
Please let me know if I answered your question correctly, or if I am missing something.

stsoe · 2025-08-07T20:33:00Z

It is possible to use GCC style mangling and write our own Windows mangler / demangler that follows the GCC style? I am asking because it would be useful to have elf files be compatible with available tools, e.g. c++filt?

Okay, that comment made no sense. We are only implementing demangle, mangling is in aiebu and is GCC style.

Sorry if my response was confusing. Let me rephrase it. AIEBU has its own implementation for mangling which follows GCC style (Itanium ABI) for pointer type arguments - https://github.com/Xilinx/aiebu/blob/49807d3f811933cacdab83094a6b1e08dc509ed7/src/cpp/preprocessor/preprocessor_input.h#L45

In this PR we are implementing demangling in XRT matching the same style which is again following GCC style(Itanium Style). If your question was, if c++filt supports this type of mangling, then on online research it says that c++filt does supports this type of mangling. c++filt can be used on Linux and Windows both. I tested on Linux and c++filt demangled the string as expected. Please let me know if I answered your question correctly, or if I am missing something.

Haha, my " didn't make sense" comment was comment to my own comment, not to yours which I hadn't seen when I wrote mine. :-)

stsoe · 2025-08-07T20:33:19Z

Please sign-off your commit(s)

donwalkarsoham · 2025-08-07T21:58:19Z

It is possible to use GCC style mangling and write our own Windows mangler / demangler that follows the GCC style? I am asking because it would be useful to have elf files be compatible with available tools, e.g. c++filt?

Okay, that comment made no sense. We are only implementing demangle, mangling is in aiebu and is GCC style.

Sorry if my response was confusing. Let me rephrase it. AIEBU has its own implementation for mangling which follows GCC style (Itanium ABI) for pointer type arguments - https://github.com/Xilinx/aiebu/blob/49807d3f811933cacdab83094a6b1e08dc509ed7/src/cpp/preprocessor/preprocessor_input.h#L45
In this PR we are implementing demangling in XRT matching the same style which is again following GCC style(Itanium Style). If your question was, if c++filt supports this type of mangling, then on online research it says that c++filt does supports this type of mangling. c++filt can be used on Linux and Windows both. I tested on Linux and c++filt demangled the string as expected. Please let me know if I answered your question correctly, or if I am missing something.

Haha, my " didn't make sense" comment was comment to my own comment, not to yours which I hadn't seen when I wrote mine. :-)

Haha ok, got it :-)

github-actions

clang-tidy made some suggestions

github-actions · 2025-08-07T22:34:14Z

src/runtime_src/core/common/api/xrt_module.cpp

+  if (it == demangle_type_map.end())
+    throw std::runtime_error("Unknown type character in mangled name: " + std::string(1, c));
+
+    return it->second;


warning: misleading indentation; statement is not part of the previous 'if' [clang-diagnostic-misleading-indentation]

return it->second; ^

Additional context

src/runtime_src/core/common/api/xrt_module.cpp:453: previous statement is here

if (it == demangle_type_map.end()) ^

larry9523 · 2025-08-07T22:35:04Z

src/runtime_src/core/common/api/xrt_module.cpp

+  if (it == demangle_type_map.end())
+    throw std::runtime_error("Unknown type character in mangled name: " + std::string(1, c));
+
+    return it->second;


github-actions · 2025-08-07T22:51:57Z

clang-tidy review says "All clean, LGTM! 👍"

stsoe · 2025-08-07T23:01:33Z

src/runtime_src/core/common/api/xrt_module.cpp

+  while (idx < mangled.size())
+    args.push_back(get_demangled_type(mangled, idx));


How about

Suggested change

while (idx < mangled.size())

args.push_back(get_demangled_type(mangled, idx));

while (idx < mangled.size())

args.push_back(get_demangled_type(mangled[idx++]));

or simpler maybe:

for (auto c : mangled) args.push_back(get_demangled_type(c));

stsoe · 2025-08-07T23:01:41Z

src/runtime_src/core/common/api/xrt_module.cpp

 static std::string
-demangle(const std::string& mangled_name)
+get_demangled_type(const std::string& s, size_t& idx)


Why does this function need s and idx.? Can't it just take char c. It feels wrong that this function updates idx. I imagine caller should do get_mangled_type(name[idx++])

Signed-off-by: Soham Donwalkar <[email protected]>

github-actions · 2025-08-07T23:49:21Z

clang-tidy review says "All clean, LGTM! 👍"

donwalkarsoham added 2 commits August 6, 2025 17:43

Add custom demangling in XRT

0968938

Signed-off-by: Soham Donwalkar <[email protected]>

Only support arg types int,char,void

0fe240b

Signed-off-by: Soham Donwalkar <[email protected]>

donwalkarsoham requested a review from stsoe as a code owner August 7, 2025 01:02

donwalkarsoham changed the title ~~Dev~~ Add custom demangler in XRT Aug 7, 2025

donwalkarsoham changed the title ~~Add custom demangler in XRT~~ Add custom demangler Aug 7, 2025

donwalkarsoham changed the title ~~Add custom demangler~~ Add custom kernel name demangler Aug 7, 2025

Remove magic numbers

410c5a8

Signed-off-by: Soham Donwalkar <[email protected]>

larry9523 requested a review from rbramand-xilinx August 7, 2025 16:56

larry9523 reviewed Aug 7, 2025

View reviewed changes

larry9523 requested changes Aug 7, 2025

View reviewed changes

stsoe reviewed Aug 7, 2025

View reviewed changes

donwalkarsoham requested a review from larry9523 August 7, 2025 17:54

github-actions bot reviewed Aug 7, 2025

View reviewed changes

donwalkarsoham requested a review from stsoe August 7, 2025 19:21

stsoe requested changes Aug 7, 2025

View reviewed changes

larry9523 reviewed Aug 7, 2025

View reviewed changes

donwalkarsoham requested review from larry9523 and stsoe August 7, 2025 22:28

github-actions bot reviewed Aug 7, 2025

View reviewed changes

larry9523 reviewed Aug 7, 2025

View reviewed changes

donwalkarsoham requested a review from larry9523 August 7, 2025 22:50

donwalkarsoham self-assigned this Aug 7, 2025

stsoe requested changes Aug 7, 2025

View reviewed changes

donwalkarsoham added 3 commits August 7, 2025 16:10

Add exception handling

af17fc0

Signed-off-by: Soham Donwalkar <[email protected]>

Remove file static map

9f00942

Signed-off-by: Soham Donwalkar <[email protected]>

Identation

f675672

Signed-off-by: Soham Donwalkar <[email protected]>

donwalkarsoham force-pushed the dev branch from dd2c6cb to f675672 Compare August 7, 2025 23:44



		// map of mangled argument types to their demangled string representations
		static const std::map<char, std::string> demangle_type_map = {

		while (idx < mangled.size())
		args.push_back(get_demangled_type(mangled, idx));

Add custom kernel name demangler #9134

Are you sure you want to change the base?

Add custom kernel name demangler #9134

Conversation

donwalkarsoham commented Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem solved by the commit

Bug / issue (if any) fixed, which PR introduced the bug, how it was discovered

How problem was solved, alternative solutions (if any) and why they were rejected

Risks (if any) associated the changes in the commit

What has been tested and how, request additional testing if necessary

Documentation impact (if any)

Uh oh!

gbuildx commented Aug 7, 2025

Uh oh!

gbuildx commented Aug 7, 2025

Uh oh!

gbuildx commented Aug 7, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

larry9523 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stsoe left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions bot Aug 7, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

donwalkarsoham commented Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stsoe commented Aug 7, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

donwalkarsoham Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

donwalkarsoham commented Aug 7, 2025

Uh oh!

stsoe commented Aug 7, 2025

Uh oh!

stsoe commented Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

donwalkarsoham commented Aug 7, 2025

Uh oh!

github-actions bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions bot Aug 7, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

donwalkarsoham commented Aug 7, 2025 •

edited

Loading

donwalkarsoham commented Aug 7, 2025 •

edited

Loading

donwalkarsoham Aug 7, 2025 •

edited

Loading

stsoe commented Aug 7, 2025 •

edited

Loading