[PATCH v1 0/7] perf symbol: Properly set DSO binary/symtab types

[PATCH v1 0/7] perf symbol: Properly set DSO binary/symtab types

[Namhyung Kim]

Hello,

Currently we have 3 types for a DSO.

* binary type: determines where to read binary instruction or data of the
  DSO.  Basically used by annotate.  Some (special) DSOs like kallsyms or
  JIT may not have the data though.

* symtab type: determines where to read symbol tables.  Set when symbols
  in the DSO are loaded.

* debug info type: determines where to read debug info.  Used by srcline,
  DWARF unwinding, data type profiling and so on.  Often debug info is
  saved in a separate file.

Some DSOs may have the same type for 3 and others can have all different.
Previously it generally assumed binary type would be same as symtab type
but now I think we should not and only set the binary type as it's used.

Also it should make sure that symtab type is set properly after loading
symbols in the DSO.

Probably this patchset won't make any practical difference in runtime
behaviors but I think it's good to track them accurately.

Thanks,
Namhyung


Namhyung Kim (7):
  perf tools: Remove redundant dso data init
  perf tools: Try linked debug files for DSO debug info
  perf symbol: Update symtab type of vmlinux from build-id cache
  perf symbol: Set binary/symtab type for split kallsyms
  perf symbol: Set dso symtab type for libbfd
  perf symbol: Set binary type for JIT map DSOs
  perf symbol: Do not set binary type from symtab type

 tools/perf/util/dso.c    |  3 +--
 tools/perf/util/symbol.c | 23 ++++++++---------------
 2 files changed, 9 insertions(+), 17 deletions(-)

-- 
2.55.0

[PATCH v1 1/7] perf tools: Remove redundant dso data init

[Namhyung Kim]

The fd and status are initialized later with cache.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
 tools/perf/util/dso.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 563a8f854c13bc21..7f389b913edb5ec7 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -1722,8 +1722,6 @@ struct dso *dso__new_id(const char *name, const struct dso_id *id)
 		dso->srclines = RB_ROOT_CACHED;
 		dso->data_types = RB_ROOT;
 		dso->global_vars = RB_ROOT;
-		dso->data.fd = -1;
-		dso->data.status = DSO_DATA_STATUS_UNKNOWN;
 		dso->symtab_type = DSO_BINARY_TYPE__NOT_FOUND;
 		dso->binary_type = DSO_BINARY_TYPE__NOT_FOUND;
 		dso->dbginfo_type = DSO_BINARY_TYPE__NOT_FOUND;
-- 
2.55.0

[PATCH v1 2/7] perf tools: Try linked debug files for DSO debug info

[Namhyung Kim]

The dso__find_dbginfo_type() should try DSO_BINARY_TYPE__DEBUGLINK so it
can follow the .gnu_debuglink and find the debug information in the
separate file.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
 tools/perf/util/dso.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 7f389b913edb5ec7..732c49c8fc3dc1a5 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -2111,6 +2111,7 @@ void dso__find_dbginfo_type(struct dso *dso)
 		DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO,
 		DSO_BINARY_TYPE__BUILDID_DEBUGINFO,
 		DSO_BINARY_TYPE__SYSTEM_PATH_DSO,
+		DSO_BINARY_TYPE__DEBUGLINK,
 		DSO_BINARY_TYPE__NOT_FOUND,
 	};
 	const enum dso_binary_type *type;
-- 
2.55.0

[PATCH v1 3/7] perf symbol: Update symtab type of vmlinux from build-id cache

[Namhyung Kim]

Currently dso__load_vmlinux() sets both binary type and symtab type to
VMLINUX.  To precisely track the symtab type of the kernel dso, update
the type to build-id cache if it's loaded from there.  It won't have
any functional difference though.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
 tools/perf/util/symbol.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 5d98888d068c741a..cf099cbd29f268ec 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -2079,7 +2079,7 @@ int dso__load_vmlinux_path(struct dso *dso, struct map *map)
 	if (filename != NULL) {
 		err = dso__load_vmlinux(dso, map, filename, true);
 		if (err > 0)
-			goto out;
+			dso__set_symtab_type(dso, DSO_BINARY_TYPE__BUILD_ID_CACHE);
 	}
 out:
 	return err;
@@ -2235,8 +2235,10 @@ static int dso__load_kernel_sym(struct dso *dso, struct map *map)
 		filename = __dso__build_id_filename(dso, NULL, 0, false, false);
 	if (filename != NULL) {
 		err = dso__load_vmlinux(dso, map, filename, true);
-		if (err > 0)
+		if (err > 0) {
+			dso__set_symtab_type(dso, DSO_BINARY_TYPE__BUILD_ID_CACHE);
 			return err;
+		}
 	}
 
 	if (!symbol_conf.ignore_vmlinux && vmlinux_path != NULL) {
-- 
2.55.0

[PATCH v1 4/7] perf symbol: Set binary/symtab type for split kallsyms

[Namhyung Kim]

When it creates new DSOs for split kallsyms, set the binary and symtab
type to KALLSYMS properly.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
 tools/perf/util/symbol.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index cf099cbd29f268ec..fc6e4dff282bc2dc 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1099,6 +1099,8 @@ static int maps__split_kallsyms(struct maps *kmaps, struct dso *dso, u64 delta,
 				return -1;
 
 			dso__set_kernel(ndso, dso__kernel(dso));
+			dso__set_binary_type(ndso, dso__binary_type(dso));
+			dso__set_symtab_type(ndso, dso__symtab_type(dso));
 			dso__set_loaded(ndso);
 
 			curr_map = map__new2(pos->start, ndso);
-- 
2.55.0

[PATCH v1 5/7] perf symbol: Set dso symtab type for libbfd

[Namhyung Kim]

It missed to set the dso symtab type when the symbols are loaded by
libbfd.  When it happens both syms_ss and runtime_ss may not be set
and won't call dso__load_sym().

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
 tools/perf/util/symbol.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index fc6e4dff282bc2dc..02b096ccbc60ac2a 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1933,6 +1933,7 @@ int dso__load(struct dso *dso, struct map *map)
 			nsinfo__mountns_enter(dso__nsinfo(dso), &nsc);
 
 		if (bfdrc == 0) {
+			dso__set_symtab_type(dso, symtab_type);
 			ret = 0;
 			break;
 		}
-- 
2.55.0

[PATCH v1 6/7] perf symbol: Set binary type for JIT map DSOs

[Namhyung Kim]

The perf-<pid>.map files contain symbol name of JIT functions.
As they don't have the binary data (instructions) no need to try
for dso_data.  Let's set the binary type regardless of the result
of symbol loading so that it can be ignored.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
 tools/perf/util/symbol.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 02b096ccbc60ac2a..389dbd7e5192f4f2 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1859,6 +1859,7 @@ int dso__load(struct dso *dso, struct map *map)
 
 	if (perfmap) {
 		ret = dso__load_perf_map(map_path, dso);
+		dso__set_binary_type(dso, DSO_BINARY_TYPE__JAVA_JIT);
 		dso__set_symtab_type(dso, ret > 0
 				? DSO_BINARY_TYPE__JAVA_JIT
 				: DSO_BINARY_TYPE__NOT_FOUND);
-- 
2.55.0

[PATCH v1 7/7] perf symbol: Do not set binary type from symtab type

[Namhyung Kim]

The DSO binary type is to access the binary (e.g. instruction) data
while symtab type is for the symbol table.  They may or may not be in
the same file.  We should track them separately and correctly.

As special binaries already set their type before loading symbols, leave
the binary type info and only update it when actually opening the DSO.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
 tools/perf/util/symbol.c | 13 -------------
 1 file changed, 13 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 389dbd7e5192f4f2..1175cb60f8206757 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1956,19 +1956,6 @@ int dso__load(struct dso *dso, struct map *map)
 
 		if (next_slot) {
 			ss_pos++;
-
-			/*
-			 * The binary type is used to find the file containing
-			 * the executed instructions, so prefer the types that
-			 * refer to the actual object over debug-only files such
-			 * as DSO_BINARY_TYPE__DEBUGLINK.
-			 */
-			if (dso__binary_type(dso) == DSO_BINARY_TYPE__NOT_FOUND ||
-			    symtab_type == DSO_BINARY_TYPE__BUILD_ID_CACHE ||
-			    (symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_DSO &&
-			     dso__binary_type(dso) != DSO_BINARY_TYPE__BUILD_ID_CACHE))
-				dso__set_binary_type(dso, symtab_type);
-
 			if (syms_ss && runtime_ss)
 				break;
 		} else {
-- 
2.55.0

Re: [PATCH v1 1/7] perf tools: Remove redundant dso data init

[sashiko-bot]

> The fd and status are initialized later with cache.
> 
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005063411.114244-1-namhyung@kernel.org?part=1

Re: [PATCH v1 3/7] perf symbol: Update symtab type of vmlinux from build-id cache

[sashiko-bot]

> Currently dso__load_vmlinux() sets both binary type and symtab type to
> VMLINUX.  To precisely track the symtab type of the kernel dso, update
> the type to build-id cache if it's loaded from there.  It won't have
> any functional difference though.
> 
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005063411.114244-1-namhyung@kernel.org?part=3

Re: [PATCH v1 4/7] perf symbol: Set binary/symtab type for split kallsyms

[sashiko-bot]

> When it creates new DSOs for split kallsyms, set the binary and symtab
> type to KALLSYMS properly.
> 
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005063411.114244-1-namhyung@kernel.org?part=4

Re: [PATCH v1 2/7] perf tools: Try linked debug files for DSO debug info

[sashiko-bot]

> The dso__find_dbginfo_type() should try DSO_BINARY_TYPE__DEBUGLINK so it
> can follow the .gnu_debuglink and find the debug information in the
> separate file.
> 
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005063411.114244-1-namhyung@kernel.org?part=2

Re: [PATCH v1 5/7] perf symbol: Set dso symtab type for libbfd

[sashiko-bot]

> It missed to set the dso symtab type when the symbols are loaded by
> libbfd.  When it happens both syms_ss and runtime_ss may not be set
> and won't call dso__load_sym().
> 
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005063411.114244-1-namhyung@kernel.org?part=5

Re: [PATCH v1 7/7] perf symbol: Do not set binary type from symtab type

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf: `perf annotate` and guest module data read broken by missing `binary_type`
--

commit 7196d300589913af007226f7522345f0d46a1af3
Author: Namhyung Kim <namhyung@kernel.org>

perf symbol: Do not set binary type from symtab type

The commit separates DSO binary type from symtab type and removes the
logic that sets the binary type from the symtab type in dso__load.

> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index 389dbd7e5192f..1175cb60f8206 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -1956,19 +1956,6 @@ int dso__load(struct dso *dso, struct map *map)
>  
>  		if (next_slot) {
>  			ss_pos++;
> -
> -			/*
> -			 * The binary type is used to find the file containing
> -			 * the executed instructions, so prefer the types that
> -			 * refer to the actual object over debug-only files such
> -			 * as DSO_BINARY_TYPE__DEBUGLINK.
> -			 */
> -			if (dso__binary_type(dso) == DSO_BINARY_TYPE__NOT_FOUND ||
> -			    symtab_type == DSO_BINARY_TYPE__BUILD_ID_CACHE ||
> -			    (symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_DSO &&
> -			     dso__binary_type(dso) != DSO_BINARY_TYPE__BUILD_ID_CACHE))
> -				dso__set_binary_type(dso, symtab_type);
> -

[Severity: Medium]
Will this removal cause perf annotate and guest module data reads to fail?

Without this logic, binary_type defaults to DSO_BINARY_TYPE__NOT_FOUND
for generic DSOs, guest kernel modules, or binaries using debuginfo/system
paths. 

When tools/perf/util/dso.c:try_to_open_dso() is later called to read data,
it only iterates over BUILD_ID_CACHE and SYSTEM_PATH_DSO when the binary
type is NOT_FOUND, completely ignoring guest-specific paths that require
machine->root_dir:

    enum dso_binary_type binary_type_data[] = {
        DSO_BINARY_TYPE__BUILD_ID_CACHE,
        DSO_BINARY_TYPE__SYSTEM_PATH_DSO,
        DSO_BINARY_TYPE__NOT_FOUND,
    };

Additionally, tools/perf/util/disasm.c:symbol__disassemble() explicitly
returns an error if binary_type remains unset:

    if (dso__binary_type(dso) == DSO_BINARY_TYPE__NOT_FOUND) {
        return SYMBOL_ANNOTATE_ERRNO__COULDNT_DETERMINE_FILE_TYPE;
    }

Does this unintentionally break disassembly for binaries not in the
build-id cache, or binary data reads for guest kernel modules?

>  			if (syms_ss && runtime_ss)
>  				break;
>  		} else {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005063411.114244-1-namhyung@kernel.org?part=7

Re: [PATCH v1 6/7] perf symbol: Set binary type for JIT map DSOs

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf: annotate regression on JIT map files due to unhandled binary type
--

commit 79781ef5615895fe2ec492b108f82094b6a0246b
Author: Namhyung Kim <namhyung@kernel.org>

perf symbol: Set binary type for JIT map DSOs

This commit explicitly sets the binary type of JIT map DSOs to JAVA_JIT. This
ensures they are identified correctly and bypass attempts to load dso_data, 
as they only contain symbol names and lack binary instructions.

> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -1859,6 +1859,7 @@ int dso__load(struct dso *dso, struct map *map)
>  
>  	if (perfmap) {
>  		ret = dso__load_perf_map(map_path, dso);
> +		dso__set_binary_type(dso, DSO_BINARY_TYPE__JAVA_JIT);

[Severity: Medium]
Does setting the binary type to DSO_BINARY_TYPE__JAVA_JIT here bypass the
historical early exit guard in symbol__disassemble()?

Looking at symbol__disassemble() in tools/perf/util/disasm.c, it guards
against unsupported files with:

    if (dso__binary_type(dso) == DSO_BINARY_TYPE__NOT_FOUND) {
        return SYMBOL_ANNOTATE_ERRNO__COULDNT_DETERMINE_FILE_TYPE;
    }

With the type now explicitly set to DSO_BINARY_TYPE__JAVA_JIT, this check
fails and allows perf annotate to incorrectly attempt disassembling the text
map file. 

The fallback binary disassemblers inevitably fail to parse the text file as
ELF and return -1. This propagates back to symbol__strerror_disassemble(),
which handles the -1 return by printing an unhelpful message to the user
instead of gracefully exiting:

    default:
        scnprintf(buf, buflen, "Internal error: Invalid %d error code\n", errnum);
        break;

Should symbol__disassemble() be updated to check for DSO_BINARY_TYPE__JAVA_JIT
so that it can exit gracefully when users try to annotate a JIT symbol profile?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005063411.114244-1-namhyung@kernel.org?part=6

Re: [PATCH v1 6/7] perf symbol: Set binary type for JIT map DSOs

[Namhyung Kim]

On Mon, Oct 05, 2026 at 06:46:16AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] perf: annotate regression on JIT map files due to unhandled binary type
> --
> 
> commit 79781ef5615895fe2ec492b108f82094b6a0246b
> Author: Namhyung Kim <namhyung@kernel.org>
> 
> perf symbol: Set binary type for JIT map DSOs
> 
> This commit explicitly sets the binary type of JIT map DSOs to JAVA_JIT. This
> ensures they are identified correctly and bypass attempts to load dso_data, 
> as they only contain symbol names and lack binary instructions.
> 
> > diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> > --- a/tools/perf/util/symbol.c
> > +++ b/tools/perf/util/symbol.c
> > @@ -1859,6 +1859,7 @@ int dso__load(struct dso *dso, struct map *map)
> >  
> >  	if (perfmap) {
> >  		ret = dso__load_perf_map(map_path, dso);
> > +		dso__set_binary_type(dso, DSO_BINARY_TYPE__JAVA_JIT);
> 
> [Severity: Medium]
> Does setting the binary type to DSO_BINARY_TYPE__JAVA_JIT here bypass the
> historical early exit guard in symbol__disassemble()?
> 
> Looking at symbol__disassemble() in tools/perf/util/disasm.c, it guards
> against unsupported files with:
> 
>     if (dso__binary_type(dso) == DSO_BINARY_TYPE__NOT_FOUND) {
>         return SYMBOL_ANNOTATE_ERRNO__COULDNT_DETERMINE_FILE_TYPE;
>     }
> 
> With the type now explicitly set to DSO_BINARY_TYPE__JAVA_JIT, this check
> fails and allows perf annotate to incorrectly attempt disassembling the text
> map file. 
> 
> The fallback binary disassemblers inevitably fail to parse the text file as
> ELF and return -1. This propagates back to symbol__strerror_disassemble(),
> which handles the -1 return by printing an unhelpful message to the user
> instead of gracefully exiting:
> 
>     default:
>         scnprintf(buf, buflen, "Internal error: Invalid %d error code\n", errnum);
>         break;
> 
> Should symbol__disassemble() be updated to check for DSO_BINARY_TYPE__JAVA_JIT
> so that it can exit gracefully when users try to annotate a JIT symbol profile?

Ok, but I think the dso__disassemble_filename() should be updated to set
binary type correctly and just use dso__get_filename().  Will do in v2.

Thanks,
Namhyung

Re: [PATCH v1 7/7] perf symbol: Do not set binary type from symtab type

[Namhyung Kim]

On Mon, Oct 05, 2026 at 06:45:30AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] perf: `perf annotate` and guest module data read broken by missing `binary_type`
> --
> 
> commit 7196d300589913af007226f7522345f0d46a1af3
> Author: Namhyung Kim <namhyung@kernel.org>
> 
> perf symbol: Do not set binary type from symtab type
> 
> The commit separates DSO binary type from symtab type and removes the
> logic that sets the binary type from the symtab type in dso__load.
> 
> > diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> > index 389dbd7e5192f..1175cb60f8206 100644
> > --- a/tools/perf/util/symbol.c
> > +++ b/tools/perf/util/symbol.c
> > @@ -1956,19 +1956,6 @@ int dso__load(struct dso *dso, struct map *map)
> >  
> >  		if (next_slot) {
> >  			ss_pos++;
> > -
> > -			/*
> > -			 * The binary type is used to find the file containing
> > -			 * the executed instructions, so prefer the types that
> > -			 * refer to the actual object over debug-only files such
> > -			 * as DSO_BINARY_TYPE__DEBUGLINK.
> > -			 */
> > -			if (dso__binary_type(dso) == DSO_BINARY_TYPE__NOT_FOUND ||
> > -			    symtab_type == DSO_BINARY_TYPE__BUILD_ID_CACHE ||
> > -			    (symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_DSO &&
> > -			     dso__binary_type(dso) != DSO_BINARY_TYPE__BUILD_ID_CACHE))
> > -				dso__set_binary_type(dso, symtab_type);
> > -
> 
> [Severity: Medium]
> Will this removal cause perf annotate and guest module data reads to fail?

I'm not sure if perf annotate would work well for guest modules.

> 
> Without this logic, binary_type defaults to DSO_BINARY_TYPE__NOT_FOUND
> for generic DSOs, guest kernel modules, or binaries using debuginfo/system
> paths. 
> 
> When tools/perf/util/dso.c:try_to_open_dso() is later called to read data,
> it only iterates over BUILD_ID_CACHE and SYSTEM_PATH_DSO when the binary
> type is NOT_FOUND, completely ignoring guest-specific paths that require
> machine->root_dir:
> 
>     enum dso_binary_type binary_type_data[] = {
>         DSO_BINARY_TYPE__BUILD_ID_CACHE,
>         DSO_BINARY_TYPE__SYSTEM_PATH_DSO,
>         DSO_BINARY_TYPE__NOT_FOUND,
>     };

I believe guest modules always need machine->root_dir to access the
file.  It won't get the correct file contents without it so the current
code didn't work well.

> 
> Additionally, tools/perf/util/disasm.c:symbol__disassemble() explicitly
> returns an error if binary_type remains unset:
> 
>     if (dso__binary_type(dso) == DSO_BINARY_TYPE__NOT_FOUND) {
>         return SYMBOL_ANNOTATE_ERRNO__COULDNT_DETERMINE_FILE_TYPE;
>     }
> 
> Does this unintentionally break disassembly for binaries not in the
> build-id cache, or binary data reads for guest kernel modules?

As I said in other reply, it should be updated to use binary type of the
dso.  I'll update the code in v2.

Thanks,
Namhyung